I agree that there are refinements to operators that are needed, such as the ability to pick which ones to import and more flexibility in shadowing them, etc. But I think that's a whole nother discussion, and I rather think that string comparison is a distinctly poor use case for it. An operator is really tailored to do one unambiguous operation with two arguments. Here, there's more than one operation when it comes to string comparison and therefore multiple arguments. Why try to fit a square peg into a round hole? It's already possible to do what you suggest with ordinary function names, so what's different here seems to come down to new syntax that IMO should be designed separately in the context of operators, not really something to do with strings.<br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 24, 2017 at 03:13 Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Breaking this into a different thread…<br class="gmail_msg">
<br class="gmail_msg">
One suggestion which I haven’t seen (maybe it is too crazy) is the idea of introducing shadowing of operators within a scope (similar to variables).<br class="gmail_msg">
<br class="gmail_msg">
Now this would need a TON of design work to make it actually work, but the gist would be:<br class="gmail_msg">
<br class="gmail_msg">
if blah == foo {<br class="gmail_msg">
//We can override/shadow the ‘<‘ operator within this scope as long as the signature is the same<br class="gmail_msg">
let (<) = String.comparisonOperation(case: .insensitive, locale: .current) //Here we grab a closure produced by a static function on String<br class="gmail_msg">
<br class="gmail_msg">
if a < b { //Within this scope < will be case insensitive<br class="gmail_msg">
//Stuff<br class="gmail_msg">
}<br class="gmail_msg">
}<br class="gmail_msg">
//Outside of the scope, < is back to it’s lovable self<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Thoughts on the general idea?<br class="gmail_msg">
<br class="gmail_msg">
Thanks,<br class="gmail_msg">
Jon<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
> I know you want to defer this for now, so feel free to set this part of the email aside, but here's a quick list of solutions I've ballparked:<br class="gmail_msg">
><br class="gmail_msg">
> 1. Your "one operand carries the options" solution.<br class="gmail_msg">
><br class="gmail_msg">
> 2. As I mentioned, do something that effectively overloads comparison operators to return them in a symbolic form. You're right about the ambiguity problem, though.<br class="gmail_msg">
><br class="gmail_msg">
> 3. Like #2, but with slightly modified operators, e.g.:<br class="gmail_msg">
><br class="gmail_msg">
> if localized(fu &< br, case: .insensitive) { … }<br class="gmail_msg">
><br class="gmail_msg">
> 4. Reintroduce something like the old `BooleanType` and have *all* comparisons construct a symbolic form that can be coerced to boolean. This is crazy, but actually probably useful in other places; I once experimented with constructing NSPredicates like this.<br class="gmail_msg">
><br class="gmail_msg">
> protocol BooleanProtocol { var boolValue: Bool { get } }<br class="gmail_msg">
><br class="gmail_msg">
> struct Comparison<Operand: Comparable> {<br class="gmail_msg">
> var negated: Bool<br class="gmail_msg">
> var sortOrder: SortOrder<br class="gmail_msg">
> var left: Operand<br class="gmail_msg">
> var right: Operand<br class="gmail_msg">
><br class="gmail_msg">
> func evaluate(_ actualSortOrder: SortOrder) -> Bool {<br class="gmail_msg">
> // There's circularity problems here, because `==` would itself return a `Comparison`,<br class="gmail_msg">
> // but I think you get the idea.<br class="gmail_msg">
> return (actualSortOrder == sortOrder) != negated<br class="gmail_msg">
> }<br class="gmail_msg">
> }<br class="gmail_msg">
> extension Comparison: BooleanProtocol {<br class="gmail_msg">
> var boolValue: Bool {<br class="gmail_msg">
> return evaluate(left.compared(to: right))<br class="gmail_msg">
> }<br class="gmail_msg">
> }<br class="gmail_msg">
><br class="gmail_msg">
> func < <ComparableType: Comparable>(lhs: ComparableType, rhs: ComparableType) -> Comparison {<br class="gmail_msg">
> return Comparison(negated: false, sortOrder: .before, left: lhs, right: rhs)<br class="gmail_msg">
> }<br class="gmail_msg">
> func <= <ComparableType: Comparable>(lhs: ComparableType, rhs: ComparableType) -> Comparison {<br class="gmail_msg">
> return Comparison(negated: true, sortOrder: .after, left: lhs, right: rhs)<br class="gmail_msg">
> }<br class="gmail_msg">
> // etc.<br class="gmail_msg">
><br class="gmail_msg">
> // Now for our special String comparison thing:<br class="gmail_msg">
> func localized(_ expr: Comparison<String>, case: StringCaseSensitivity? = nil, …) -> Bool {<br class="gmail_msg">
> return expr.evaluate(expr.left.compare(expr.right, case: case, …))<br class="gmail_msg">
> }<br class="gmail_msg">
><br class="gmail_msg">
> 5. Actually add some all-new piece of syntax that allows you to add options to an operator. Bad part is that this is ugly and kind of weird; good part is that this could probably be used in other places as well. Strawman example:<br class="gmail_msg">
><br class="gmail_msg">
> // Use:<br class="gmail_msg">
> if fu < br %(case: .insensitive, locale: .current) { … }<br class="gmail_msg">
><br class="gmail_msg">
> // Definition:<br class="gmail_msg">
> func < (lhs: String, rhs: String, case: StringCaseSensitivity? = nil, …) -> Bool { … }<br class="gmail_msg">
><br class="gmail_msg">
> 6. Punt on this until we have macros. Once we do, have the function be a macro which alters the comparisons passed to it. Bad part is that this doesn't give us a solution for at least a version or two.<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>