[swift-evolution] ternary operator ?: suggestion
possen at gmail.com
Sun Dec 13 10:45:25 CST 2015
> On Dec 13, 2015, at 3:59 AM, Al Skipp <al_skipp at fastmail.fm> wrote:
>> On 13 Dec 2015, at 05:54, Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Hello All,
>> Been sick in bed all day, but decided to try to be productive…
>> I did a rough draft of a proposal for implementing if expressions and switch expressions based upon the discussions we had here. I have tried to keep the scope of the changes as small as possible, only added one keyword and kept things as similar to the existing language constructs as possible. If anyone wants to help me with this, or has feedback, please let me know,
>> https://github.com/possen/swift-evolution/blob/master/0020.md <https://github.com/possen/swift-evolution/blob/master/0020.md>
>> - Paul
> Thanks for taking the time to put this detailed proposal together.
> Regarding the if…then…else expression, it all looks good to me.
> I have a few comments on the proposed switch expression:
> Is it worth reusing the ‘then’ keyword, instead of colon? If a new keyword is to be added, it’d be good if it wasn’t restricted to only one use. The advantage of using ‘then’ in switch would be to further distinguish the expression from the statement and would fit with the if…then…else expression. The disadvantage is that it adds a little more verbosity (ideally, expressions should be syntactically light-weight).
I was doing my best to stay with with the existing model for switch if possible so using the existing constructs both make the implementation simpler and hopefully consistent with the way switch currently works. The main change here is that each part is an expression instead of statement(s) otherwise it is the same old switch but usable where you would have expressions.
> Having the ‘case’ keyword appear only once, looks a bit odd to me, it gives the impression that it is only associated with the first case.
> My preference would be to omit the ‘case’ keyword entirely. In the switch statement it can be helpful, as the cases can run over several lines, therefore the keyword is a handy visual marker for the different cases. The expression for each case should only be one line, so this visual marker shouldn’t be required for switch expressions. Having said that, I understand if people think this is too much of a change. Therefore my suggestion is, either the ‘case’ keyword is omitted from the expression, or it is associated with every case as it currently is with the switch statement.
I explored adding “cases” which could be interchanged with “case” but decided against it because it would add another keyword. Also, the idea was to have this work the same as the switch statement. Currently switch statements allow you to have a single word “case” followed by multiple comma separated cases. Since case and cases would just behave the same, I am not opposed to adding back in if there is significant benefit in readability.
> It might be worth showing an example of binding to associated values in a enum using a switch expression? However, the behaviour should be identical to the switch statement, so this might not be required.
Ok will add that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution