Seems like a good solution to me.
> On 24 Jan 2017, at 05:29, Gwendal Roué via swift-evolution > <[email protected]> wrote: > > >> Le 24 janv. 2017 à 04:31, Brent Royal-Gordon via swift-evolution >> <[email protected]> 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 = '[email protected]' 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) == "[email protected]") > > Yes, it comes with extra operators so that nonsensical comparison are avoided. > > But it just works. > > Gwendal > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
