[swift-evolution] Strings in Swift 4

[Gwendal Roué]

Now that I think more about it, tainting strings with a comparison behavior may be a bad idea:

	// not a so good idea, after all
	let foo = "foo".comparison(case: .insensitive, locale: .current)

Problems are:

- Two strings tainted with the same comparison behavior should be comparable, but two strings tainted with different behaviors should not. I'm not sure that the Swift type system allows that. In the current state of affairs, such restrictions are only available to *types*, which implies that comparisons should be types as well. But types can't be built at runtime from other types: there's not way for a runtime-chosen locale to be able to build a type.

- Tainting strings is an old, and unsolved problem. If you're allowed to taint for comparison, why can't you taint for confidence (user input), needing escaping (for HTML, shell, SQL, javscript, etc.), and a whole bunch of other dimensions I don't even think of? We're already discussing different types for strings and substrings... Do we really want a combinatorial explosion of types?

- Should we restrict support for comparison behaviors to strings only? `Sequence.lexicographicallyPrecedes(_:by:)` is interested in comparison behaviors as well, and it extends much further than just Strings.

So all in all, I think that isolating comparison behaviors from Strings may be a much better idea.

Gwendal

> Le 24 janv. 2017 à 08:18, David Hart <david at hartbit.com> a écrit :
> 
> Seems like a good solution to me.
> 
> On 24 Jan 2017, at 05:29, Gwendal Roué via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 
>>> Le 24 janv. 2017 à 04:31, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/1ddf575b/attachment.html>