> On Jun 11, 2017, at 10:25 PM, David Hart via swift-evolution
> <[email protected]> wrote:
>
>
> On 11 Jun 2017, at 02:49, Ben Cohen <[email protected]
> <mailto:[email protected]>> wrote:
>
>>
>>> On Jun 8, 2017, at 10:32 AM, David Hart via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Hello,
>>>
>>> When working with Strings which are known to be ASCII, I tend to use the
>>> UTF16View for the performance of random access. I would also like to have
>>> the convenience of indexing with Int:
>>>
>>> let barcode = "M1XXXXXXXXX/CLEMENT EELT9QBQGVAAMSEZY1353 244 21D 531
>>> 10A1311446838”
>>> let name = barcode.utf16[2..<22]
>>> let pnrCode = barcode.utf16[23..<30]
>>> let seatNo = barcode.utf16[47..<51]
>>> let fromCity = barcode.utf16[30..<33]
>>> let toCity = barcode.utf16[33..<36]
>>> let carrier = barcode.utf16[36..<39]
>>> let flightNumber = barcode.utf16[39..<44]
>>> let day = barcode.utf16[44..<47]
>>>
>>> I define my own subscript in an extension to UTF16View but I think this
>>> should go in the Standard Library.
>>> Any thoughts?
>>>
>>> David.
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> Hi David,
>>
>> My view is positional shredding of strings is enough of a use case that we
>> ought to think about handling it better. I don’t think having to convert the
>> string into an Array of Character, or bytes, or use Data, should be
>> necessary, since this implies losing the stringiness of the slices you are
>> creating, which is an inconvenience for many use cases. Strings-as-data is a
>> thing we should support, and support well.
>>
>> But I also don’t think giving String or its views integer indices is the
>> right way to go either, incorrectly implying as it does random access
>>
>> (or, even if we did end up making utf16 permanently random-access,
>> encouraging people towards using utf16 to support this use case when often
>> they’d be better served sticking with characters).
>>
>> There’s a few things to note about the example you give:
>> 1) Do you really want utf16 view slices for your variable types? Maybe in
>> this case you do, but I would guess a lot of the time what is desired would
>> be a (sub)string.
>
> Not really. I would be quite happy with Substring. The variable type is just
> the consequence of my choice of the UTF16 view.
>
>> 2) Do you really want to hard-code integer literals into your code? Maybe
>> for a quick shell script use case, but for anything more this seems like an
>> anti-pattern that integer indices encourage.
>
> I agree. I took the code out of a project of mine and simplified it. I have
> the Int ranges defined as named constants.
>
>> 3) Are you likely to actually want validation at each step – that the string
>> was long enough, that the string data was valid at that point?
>
> No. I pre-validate the string and it's length beforehand.
>
>> 4) This case doesn’t seem to need random access particularly, so much as the
>> (questionable? see above) convenience of integer indexing. Although
>> reordered in the example, it seems like the code could be written to
>> progressively traverse the string from left to right to get the fields.
>> Unless the plan is to repeatedly access some fields over and over. But I’m
>> not sure we’d want to put affordances into the std lib to encourage
>> accessing stringly typed data...
>
> Indeed. I initially rewrote the code to traverse the string from left to
> write, advancing indices by deltas. But (1) it made the code less readable,
> (2) further removed from the barcode spec which is defined in terms of
> offsets, and (3) more brittle - editing deltas forces chain modifications:
>
> let nameStart = barcode.index(name.startIndex, offsetBy: 2)
> let nameEnd = barcode.index(nameStart, offsetBy: 20)
> let name = barcode[nameStart..<nameEnd]
>
> let pnrCodeStart = barcode.index(nameEnd, offsetBy: 1)
> let pnrCodeEnd = barcode.index(pnrCodeStart, offsetBy: 7)
> let pnrCode = barcode[pnrCodeStart..<pnrCodeEnd]
>
>> So the question is, what affordances should we put into the standard
>> library, or maybe other libraries, to help with these use cases? This is a
>> big design space to explore, and at least some ideas ought to feed into our
>> ongoing improvements to String for future releases.
>>
>> For example:
>>
>> Now that we have Substring, it opens up the ability to efficiently consume
>> from the front (since it’s just adjusting the substring range):
>>
>> extension Collection where Self == SubSequence {
>> // or some better name...
>> mutating func removeFirst(_ n: IndexDistance) -> SubSequence? {
>> guard let i = index(startIndex, offsetBy: n, limitedBy: endIndex)
>> else { return nil }
>>
>> defer { self = self[i...] }
>> return self[..<i]
>> }
>> }
>>
>> Once you have this, you could use it to write the example code, along with
>> some error checking (or you could use ! if you were completely certain of
>> the integrity of your data)
>>
>> var s = barcode[...] // make a substring for efficient consumption
>> _ = s.consume(2) // drop initial prefix
>> guard let name = s.removeFirst(20)?.trim else { fatalError("Failed to read
>> name") }
>> guard let pnrCode = s.removeFirst(6).map(PNRCode.init) else {
>> fatalError("Failed to read pnrCode") }
>
> Definitely interesting! But it has some of the same issues as my code above.
>
This has one less issue than your code above: because it works on Characters
you’ll get proper grapheme breaking. Even for ASCII, the provided code is safer
as grapheme breaking is almost-but-not-quite-trivial for ASCII. To have code
units be the same as Characters, you’ll need to validate that it is both ASCII
*and* does not contain a CR-LF sequence inside, as CR-LF is a single grapheme.
This is not intuitive right away and is a good example of the kinds of traps
that can arise when working directly on code units rather than Character, even
if all ASCII. This can cause seemingly well tested code to blow up in
production.
>> Or you could build on the above to create a function that could shred a
>> string into a dictionary of fields… (probably a bit domain-specific for the
>> std lib at this point)
>>
>> extension Collection {
>> // could choose to handle or fail on gaps, out-of-order ranges,
>> overlapping ranges etc
>> func fields<P: Collection>(at positions: P) -> [String:SubSequence]? //
>> or throw an error with a field name
>> where P.Element == (key: String, value: CountableRange<IndexDistance>)
>> }
>>
>> let barcodeSchema: DictionaryLiteral = [
>> "name": 2..<22,
>> "pnrCode": 23..<30,
>> "fromCity": 30..<33,
>> "toCity": 33..<36,
>> "carrier": 36..<39,
>> "flightNumber": 39..<44,
>> "day": 45..<47,
>> "seatNo": 47..<51,
>> ]
>>
>> let fields = barcode.fields(at: barcodeSchema)!
>
> This brings us back to more natural (for this algorithm) Int ranges, but it
> does require writing the extra extension. And if that's the case, it's easier
> to just write a string Int range subscript extension.
>
> What I was hoping the Standard Library would provide an opt-in, slightly less
> safe but more convenient, pragmatic solution.
Could you elaborate on what you mean by “less safe”?
> In a similar way, the language lets us use the unwrapping operator to unwrap
> an optional we know to be non-nil. It's not as safe as optional binding, but
> it makes the code more readable for cases where we know more than the type
> system can provide. I don't know if I'm making sense.
In the case of unwrapping, the safety given up is clear and the semantics are
very obvious. For anything involving Unicode, correctness is non-obvious and
corner cases can be treacherous.
> _______________________________________________
> swift-evolution mailing list
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
