[swift-evolution] Strings in Swift 4

[Dave Abrahams]

on Sat Feb 04 2017, Saagar Jha <swift-evolution at swift.org> wrote:

> Sorry, it looks like I left you hanging on this–luckily I found it when I was cleaning my inbox.
>
> Overall, I believe the issue I have with the Swift String indexing
> model is that indices cannot be operated on like an Int can–you can
> multiply, divide, square, whatever you want on integer indices, while
> String.Index only allows for what is essentially addition and
> subtraction. Now, I get that these operations may not make sense on
> most Strings; the existing API covers them well. However, there are
> cases, where these operations would be convenient; such as when
> dealing with fixed-length records or tables of data; almost invariably
> these are stored as ASCII. Thus, for these cases, I believe that there
> should be some way to let String know that we are dealing with
> something that is purely ASCII, so that it can allow us to use these
> operations in an efficient manner (for example, having an optional
> .asciiString property that conforms to RandomAccess; since I don’t
> believe that extendedASCII does). 

We could decide to make it random access at the cost of ruling out some
less-used but still-significant encodings of the string's backing store,
such as Shift-JIS.  I personally am unconvinced that the marginal extra
convenience gained by random access to extendedASCII would be worth the
loss of the ability to operate directly on such encodings.

> Such an API would keep the existing String paradigm, which is what is
> needed most of the time, but allowing for random access when the data
> can be guaranteed to support it.

We can easily make an ASCIIString that conforms to Unicode and provides
RandomAccessCollection conformance to all of its views.  That random
access would not be preserved **in the type system** when ASCIIString is
wrapped in a String—the String's ExtendedASCIIView would only conform to
BidirectionalCollection—but the underlying efficiency characteristics
*would* be preserved, dynamically.

> I’m not sure if I’m getting my point across, please do let me know if
> you don’t quite get what I mean.

I'm pretty sure I get what you mean.  Let me know if you don't think so.

> Saagar Jha
>
>> On Jan 20, 2017, at 5:55 PM, Ben Cohen <ben_cohen at apple.com> wrote:
>> 
>> 
>>> On Jan 20, 2017, at 2:58 PM, Saagar Jha via swift-evolution
>>> <swift-evolution at swift.org
>>> <mailto:swift-evolution at swift.org>>
>>> wrote:
>>> 
>>> Sorry if I wasn’t clear; I’m looking for indexing using Int, instead of using formIndex.
>> 
>> 
>> Question: why do you think integer indices are so desirable?
>> 
>> Integer indexing is simple, but also encourages anti-patterns
>> (tortured open-coded while loops with unexpected fencepost errors,
>> conflation of positions and distances into a single type) and our
>> goal should be to make most everyday higher-level operations, such
>> as finding/tokenizing, so easy that Swift programmers don’t feel
>> they need to resort to loops as often.
>> 
>> Examples where formIndex is so common yet so cumbersome that it
>> would be worth efforts to create integer-indexed versions of string
>> might be indicators of important missing features on our collection
>> or string APIs. So do pass them along.
>> 
>> (There are definitely known gaps in them today – slicing needs
>> improving as the manifesto mentions for things like slices from an
>> index to n elements later. Also, we need support for in-place
>> remove(where:) operations. But the more commonly needed cases we
>> know about that aren’t covered, the better)
>> 
>> 
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

-- 
-Dave