[swift-evolution] ternary operator ?: suggestion
Thorsten Seitz
tseitz42 at icloud.com
Mon Dec 14 10:24:16 CST 2015
I think there's been a misunderstanding or two...
First I proposed that if if-expressions would be written with "then" then if-statements should use "then", too, for consistency. Always, not optionally.
Second I would require if-expressions to always have an "else" clause (as opposed to proposals that suggested to interpret missing "else" clauses as "else nil", i.e making the result type of the if-expression optional).
-Thorsten
> Am 13.12.2015 um 20:50 schrieb J. Cheyo Jimenez via swift-evolution <swift-evolution at swift.org>:
>
> "or we could go with an optional “then” for statements as was suggested by Thorsten. "
>
> I don't think this should go in the proposal. An else is alway required in a guard statement, an expression should not return an optional imho.
>
>
>
>> On Sunday, December 13, 2015, Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>
>>> On Dec 13, 2015, at 8:11 AM, Jakob Egger <jakob at eggerapps.at> wrote:
>>>
>>> I really don't like the "if cond then expr1 else expr2".
>>>
>>> 1) First of all, it's extremely verbose. It's almost as bad as the SQL construct "case when cond then expr1 else expr2 end”.
>>
>> Yeah it adds a few characters overall. What used to be 2 chars now takes 10. Clarity is preferred though by many. I head frequently people telling users to never use ternary operators because they are confusing to read.
>>
>>>
>>> 2) It makes Swift harder to learn. Newcomers will be confused why you sometimes need to use curly braces and why at other times you need to use the "then" keyword.
>>
>> I did mention this in Alternatives Considered section. By making the else part required, this emphasizes that it is different or we could go with an optional “then” for statements as was suggested by Thorsten.
>>>
>>> 3) It doesn't help when you want to do multi-line calculations
>>
>> This is the case with the ternary as well, I think it is better to keep it simple.
>>>
>>> But there is one good side to this proposal: it nests more naturally than the ternary operator:
>>> "if cond then expr1 else if cond2 then expr2 else expr3"
>>> vs.
>>> "cond ? expr1 : (cond2 ? expr2 : expr3)
>>>
>>> The proposed syntax for the switch statement is so confusing that I really don't think it is a good idea.
>>
>> Not sure why that is, it is essentially the same as the existing switch statement except everything is an expression instead of statements. Is there anything I can do in the examples or documentation to make things clearer?
>>
>>>
>>> Why not just allow normal if statements to return values?
>>> I don't see what's so bad about the following:
>>> "let value = if cond {expr1} else {expr2}"
>>>
>>> This would also extend to multiple lines:
>>> let value = if cond {
>>> expr1
>>> } else {
>>> let something = Object()
>>> something.doStuff()
>>> something
>>> }
>>
>> I answered this with others, also notice how there are braces everywhere? does that really work when you just want to put something on one line. What happens when one of your branches returns void? Expressions are guaranteed to have a result, statements don’t make such a guarantee.
>>
>>
>>
>>> Jakob
>>>
>>>> On 13 Dec 2015, at 06:54, Paul Ossenbruggen via swift-evolution <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
>>>>
>>>> Thanks,
>>>> - Paul
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> 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/20151214/e2fc8744/attachment.html>
More information about the swift-evolution
mailing list