[swift-evolution] ternary operator ?: suggestion

[Craig Cruden]

On the where/if conditional clause being omitted…. if that is done it will lead to more convoluted code since people will end up nesting in ternary below the “switch/match” to accomplish that where a simple filter would have left it at one level of code.


> On 2016-01-07, at 15:10:28, Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi Chris, 
> 
> I agree now, finally, it took a while, that ternary as it stands is pretty likely entrenched. And I apologize that this has gone on for so long. Thank you for your detailed feedback.
> 
> Just a few hopefully quick questions:
> 
> Do you have any thoughts on supporting two forms? Like the compact form where case and default are not present, and the more formal switch like form? It seems like having the word “case" repeated could reduce the compactness benefits especially on single line expressions and thus make the suggestion less appealing for approval.
> 
> Do you have any specific reasons to not support “where”? Is it just to keep it simple and when we need more complexity use the statement form? 
> 
> Thanks!
> 
> - Paul
> 
>> On Jan 6, 2016, at 11:23 PM, Chris Lattner <clattner at apple.com> wrote:
>> 
>> 
>>> On Jan 6, 2016, at 8:35 PM, Paul Ossenbruggen via swift-evolution <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
> https://lists.swift.org/mailman/listinfo/swift-evolution