[swift-evolution] Strings in Swift 4

[David Hart]

Seems like a good solution to me.

> On 24 Jan 2017, at 05:29, Gwendal Roué via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> Le 24 janv. 2017 à 04:31, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>>>> The operands and sense of the comparison are kind of lost in all this garbage. You really want to see `foo < bar` in this code somewhere, but you don't.
>>> 
>>> Yeah, we thought about trying to build a DSL for that, but failed.  I think the best possible option would be something like:
>>> 
>>>  foo.comparison(case: .insensitive, locale: .current) < bar
>>> 
>>> The biggest problem is that you can build things like
>>> 
>>>    fu = foo.comparison(case: .insensitive, locale: .current)
>>>    br = bar.comparison(case: .sensitive)
>>>    fu < br // what does this mean?
>>> 
>>> We could even prevent such nonsense from compiling, but the cost in library API surface area is quite large.
>> 
>> Is it? I think we're talking, for each category of operation that can be localized like this:
>> 
>> * One type to carry an operand and its options.
>> * One method to construct this type.
>> * One alternate version of each operator which accepts an operand+options parameter. (I'm thinking it should always be the right-hand side, so the long stuff ends up at the end; Larry Wall noted this follows an "end-weight principle" in natural languages.)
>> 
>> I suspect that most solutions will at least require some sort of overload on the comparison operators, so this may be as parsimonious as we can get. 
> 
> SQL has the `collate` keyword:
> 
> 	-- sort users by email, case insensitive
> 	select * from users order by email collate nocase
> 	-- look for a specific email, in a case insensitive way
> 	select * from users where email = 'foo at example.com' collate nocase
> 
> It is used as a decorator that modifies an existing sql snippet (a sort descriptor first, and a comparison last)
> 
> When designing an SQL building to Swift, I chose the `nameColumn.collating(.nocase)` approach, because it allowed a common Swift syntax for both use cases:
> 
> 	// sort users by email, case insensitive
> 	User.order(nameColumn.collating(.nocase))
> 	// look for a specific email, in a case insensitive way
> 	User.filter(nameColumn.collating(.nocase) == "foo at example.com")
> 
> Yes, it comes with extra operators so that nonsensical comparison are avoided.
> 
> But it just works.
> 
> Gwendal
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170124/ecdd3f1d/attachment.html>