Understood. Luckily we had a pretty decent test suite that caught this.
Thanks for working through that with me Philippe.
On Thu, Aug 24, 2017, at 03:35 PM, Philippe Hausler wrote:
> This is expected behaviors of collections and their slices. The
> previous result was a bug.>
> I agree that collections in general and their slices need more
> documentation.>
> Sent from my iPhone
>
> On Aug 24, 2017, at 11:28 AM, Ryan Lovelett <swift-
> d...@ryan.lovelett.me> wrote:>> I think your onto it Philippe but then why is
> it behaving that way?
>>
>> I updated my earlier script (attached) and added 2 things.
>>
>> 1. print("Start: \(data.startIndex), End: \(data.endIndex), Count:
>> \(data.count)") after the data.removeFirst(4).>> 2. The startIndex
>> offset you suggested.
>>
>> It no longer crashes. Hooray!
>>
>> Swift 3.1:
>>
>> Start: 0, End: 2, Count: 2
>> Base64: QWE=, String: Aa
>>
>> Swift 3.2:
>>
>> Start: 4, End: 6, Count: 2
>> Base64: QWE=, String: Aa
>>
>> Oh wait. Woah. That's a really subtle change that has some very real
>> consequences.>>
>> Is this expected and/or documented? Because I certainly would not
>> have expected that drastic of a change. I'll obviously need to go
>> read a lot more of the changes between Swift 3.1 and Swift 3.2 if
>> these sorts of changes are in scope.>>
>>
>> On Thu, Aug 24, 2017, at 02:10 PM, Philippe Hausler wrote:
>>> I see the issue.. the latest version traps (appropriately so).
>>>
>>> let str = String(bytes: data[..<2], encoding: .utf8)!
>>>
>>> The sub-range of the slice you have is incorrectly indexed. Try this
>>> out (I am presuming this is what you mean):>>>
>>> let str = String(bytes: data[data.startIndex..<(data.startIndex +
>>> 2)], encoding: .utf8)!>>>
>>>> On Aug 24, 2017, at 11:07 AM, Philippe Hausler <phaus...@apple.com>
>>>> wrote:>>>>
>>>> Is there a radar or bugs.swift.org ticket filed on this?
>>>>
>>>> I presume because of the import this is a Darwin thing and not a
>>>> linux thing.>>>>
>>>>> On Aug 24, 2017, at 11:05 AM, Michael Gottesman via swift-dev <swift-
>>>>> d...@swift.org> wrote:>>>>>
>>>>>
>>>>>> On Aug 24, 2017, at 10:47 AM, Ryan Lovelett via swift-dev <swift-
>>>>>> d...@swift.org> wrote:>>>>>>
>>>>>> I've found what I believe is a bug. Though I'm unclear if the bug
>>>>>> is in>>>>>> Swift 3.1 or Swift 3.2/4.0. All I can say for sure is the
>>>>>> behavior is>>>>>> quite drastically different between the two.
>>>>>>
>>>>>> For the code below (and attached):
>>>>>>
>>>>>> import Cocoa
>>>>>>
>>>>>> var data = Data(bytes: [0x50, 0x4B, 0x01, 0x02, 0x41, 0x61])
>>>>>> data.removeFirst(4)
>>>>>> let base64 = data.base64EncodedString()
>>>>>> let str = String(bytes: data[0..<2], encoding: .utf8)!
>>>>>> print("Base64: \(base64), String: \(str)")
>>>>>>
>>>>>> If I compile and run that with the Swift included in Xcode 8.3.3
>>>>>> (e.g.,>>>>>> swift ./data-bug.swift) it outputs: Base64: QWE=, String:
>>>>>> Aa.
>>>>>> Which is>>>>>> what I expect.
>>>>>>
>>>>>> With the Swift that is included with Xcode 9.0 beta 6 (9M214v)
>>>>>> (e.g.,>>>>>> swift -swift-version 3 ./data-bug.swift). It performs an
>>>>>> illegal>>>>>> hardware instruction and crashes. It also does this if I
>>>>>> use use
>>>>>> the>>>>>> version 4 of the compiler.
>>>>>>
>>>>>> Is this a bug? If so where is the bug? Was this always meant to
>>>>>> not work>>>>>> and Swift 3.1 just happened to work or is there now an
>>>>>> issue in
>>>>>> the>>>>>> Swift 3.2 implementation?
>>>>>
>>>>> I have not engaged my brain with the particulars of the rest of
>>>>> the email, but high level question: does this happen without
>>>>> optimization? Or does it happen only with optimization?>>>>>
>>>>> Michael
>>>>>
>>>>>> <data-bug.swift>_______________________________________________
>>>>>> swift-dev mailing list
>>>>>> swift-...@swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>>>>
>>>>> _______________________________________________
>>>>> swift-dev mailing list
>>>>> swift-...@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-dev
>>
>> <data-bug.swift>
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
