[swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen]

Interesting and impressive you could do that much with the language as it stands. Thanks for sharing this and your efforts it shows the power of the language! I don’t think a library approach is going to be satisfactory to gain widespread usage though. Your use of switch statements is cool but does not have the advantages that I would like to see, like avoiding putting return in there. 



> On Jan 7, 2016, at 12:44 AM, Jo Albright <me at jo2.co> wrote:
> 
> Since I wanted to start playing with this feature now to see how I would use it. I went ahead and built the beginning of a library https://github.com/joalbright/Switchary <https://github.com/joalbright/Switchary> (feel free to add to it, I plan on continuing to support and advance it until Swift gives me reason not to)
> 
> :) Yes it is called Switchary… just trying to have some fun. I know it is more verbose than what would be available if it were apart of the stdlib, but I am impatient.
> 
> 
>  Nerd . Designer . Developer
> Jo Albright
> 
> 
>> On Jan 7, 2016, at 2:23 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Jan 6, 2016, at 8:35 PM, Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hi Charles,
>>> 
>>> Chris, already said he did not like ? being used for ternary because it was already used for optionals. I think because of historical precedent it may be acceptable here.  I have tried combos earlier with ! and got no support, admittedly not with the same usage as yours. 
>> 
>> Hi Paul (and others),
>> 
>> Here’s an updated opinion from me - keep in mind that this isn’t gospel, just my opinion, and subject to change :-)  
>> 
>> Basically I’ve settled on the idea that there is nothing better-enough that would be worth changing the ternary ?: for.  Anything we came up with would be “weird” and diverge from any existing practice out there, and therefore be impossible to justify.  That’s why I updated the commonly_proposed.md list.
>> 
>> That said, I think that the terseness that ?: provides is important.  If you can agree to both points, it sounds like that means that ?: is here to stay, with its existing spelling.  This also means that the dream of divorcing ?: from optional syntax has failed.
>> 
>> 
>> That leaves us with the question of what to do with switch-as-expression.  I’m still pretty unmotivated by any of the ML/haskell like syntaxes that lead to giant hanging statements-like things indented to the right.  Instead, the idea of embracing the weirdness that is ?: and extending it to pattern matching feels like the best path.  Something akin to:
>> 
>> let x = someValue ? 
>>   case <pattern1>: result1
>>   case <pattern2>: result2
>>   case <pattern3>: result3
>>   default: result4
>> 
>> would make sense: it is totally unambiguous (‘?' followed by ‘case’ drives this, and goes until a default case). The presence of the (strongly syntax highlighted) case statements means that people can flow this onto a single line if they want, and I also like it that provides a way to get the power of “if case/else” inline in an expression as well for the simplest pattern matching cases (e.g. checking for one enum value, or matching a string value against a regex someday).
>> 
>> If we went with this, I think it would make sense to keep colons, and use refutable patterns (as seen in switch statements) as the pattern grammar.  I’d lean towards not allowing where clauses on the patterns, and the results would obviously have to be single expressions (without a return or other statement) just like ?:.  Perhaps that syntax should require or allow commas between the cases, I don’t have a strong opinion about that.
>> 
>> 
>> So in terms of the ideas you are kicking around, this one seems promising to me.  That said, there is still a huge and hard question to answer here: would this feature pay for itself?  It is clear that any feature of this ilk will be making the language more complex.  Would code that uses it actually be *better* (e.g. more *clear*) than code that isn’t using it today?  What ways can be measured to justify adding this to Swift?
>> 
>> -Chris
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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/20160107/551610bc/attachment.html>