[swift-evolution] ternary operator ?: suggestion

Tue Dec 15 11:25:44 CST 2015

Got it. I'll revise this.  Thank you.

On Tuesday, December 15, 2015, Jordan Rose <jordan_rose at apple.com> wrote:

> Specifically on this point:
>
> The use of 'then' is more of a modifier to the 'if' statement than a
> keyword so it should be possible to allow the use of then in the same
> way 'let required = 1 ; let convenience = 1' is legal in swift.
>
>
> We can get away with this because 'required' and 'convenience' only appear
> in a type, where arbitrary expressions are not allowed. In this case,
> 'then' is a separator between two expressions. We can probably recover if
> the user forgets it, but only if it's a true keyword.
>
> I'll repost what I said on another thread: when adding new syntax, it's
> important to consider not just complete, correct code, but also the
> possible error and intermediate states that the compiler and SourceKit have
> to deal with.
>
> Jordan
>
>
>
> On Dec 15, 2015, at 8:38 , J. Cheyo Jimenez via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
> Thank you Paul for the initial draft.
>
> Here is the a draft version that I intend to submit.
>
>
> https://github.com/masters3d/swift-evolution/blob/ReplaceTernary/proposals/00-Replace%20%3F:%20Ternary%20Operator%20with%20if-then-else%20expression.md
>
> On Monday, December 14, 2015, Paul Ossenbruggen via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
>> Agreed, I was thinking to I really want turn something that was 2
>> characters into 10 and will I really be happy with that at the end of the
>> day. A properly formatted ternary can be quite easy to read, it is when
>> people get sloppy and try to cram too much into one expression that they
>> get really hard to follow. For example,
>>
>>     return (a<b) ? (b<c) ? b : (a<c) ? c : a : (a<c) ? a : (b<c) ? c : b;
>>
>> If formatted like this becomes easier follow the logic (at least to me):
>>
>> return a < b
>> ? b < c
>> ? b
>> : a < c
>> ? c
>> : a
>> : a < c
>> ? a
>> : b < c
>> ? c
>> : b
>>
>> Is this new syntax helping?
>>
>> return if a < b
>> then if b < c
>> then b
>> else if a < c
>> then c
>> else a
>> else if a < c
>> then a
>> else if b < c
>> then c
>> else b
>>
>> I found this translation quite tricky to do. maybe parens help?
>>
>> return (if a < b
>> then (if b < c
>> then b
>> else (if a < c
>> then c
>> else a))
>> else (if a < c
>> then a
>> else (if b < c
>> then c
>> else b)))
>>
>> Not really and I still I found this hugely frustrating, so much so that I
>> am going to drop all support for this proposal and remove my name from it.
>> If anyone wants to take over feel free.
>>
>> Others still keen on the idea should try this experiment. It convinced me
>> is horrible idea :-) I don’t want to be blamed for it by every Swift
>> programmer in the future.
>>
>> I do still however like the Swift Expressions.
>>
>> - Paul
>>
>>
>>
>> On Dec 14, 2015, at 4:50 PM, Nick Shelley via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> I however frequently hear people saying ternary should be avoided because
>>> they are hard to read or they hate them.
>>
>>
>> FWIW, I used to be one of those people, but then started working on a
>> team where one member liked them. He didn't force them on us, but after
>> enough code reviews where he showed us how to turn 5-line if/else
>> statements into simple one-line ternary expressions, I got used to reading
>> them and now love them and use them often.
>>
>> People also hate map, flatMap, reduce, etc., for the same reasons (it's
>> hard for them to read because it's not the for loop they're used to). I
>> think it's a simple matter of getting used to it.
>>
>> On Mon, Dec 14, 2015 at 11:57 AM, Chris Lattner via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>>
>>> On Dec 14, 2015, at 12:19 AM, Paul Ossenbruggen via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> Once again, thank you for all the feedback, if I sound in anyway grumpy
>>> in responding to any email, it has a bit more to do with my cold than the
>>> suggestions.
>>>
>>> I have split the original proposal into two proposals and incorporated a
>>> bunch of feedback. Splitting it up has been extremely good, not only does
>>> it improve readability, I am actually finding I could take or leave the
>>> ternary replacement idea. But the proposal will be there if enough everyone
>>> thinks it is a good idea. We could put it to a vote to see if there is
>>> enough interest and I would be happy to take it further if there is. I
>>> suspect this thread would not exist at all if there was no interest in it.
>>> However, I am finding I am far more interested in getting switch
>>> expressions.
>>>
>>> Ternary Replacement
>>> https://github.com/possen/swift-evolution/blob/master/0021.md
>>>
>>>
>>> Quick comment.  The proposal states:
>>>
>>>
>>> Is it really better? Why not just keep ternary expressions?
>>> This is a valid question, there is an advantage in compactness to
>>> ternary expressions. I however frequently hear people saying ternary should
>>> be avoided because they are hard to read or they hate them. There seems to
>>> many who either stronly dislike it or don't care.
>>>
>>>
>>> However, it doesn’t actually show that it is solving the objections
>>> people have to the ternary operator.  It is true that some people find the
>>> ?: syntax weird, but an equal number of people say that the problem is that
>>> you’re putting complex conditional logic inline into the middle of an
>>> expression - this proposal actually makes that objection worse.  There are
>>> also other objections to ?:, and until you enumerate them, it is hard to
>>> see whether this proposal is making things better or worse.
>>>
>>> -Chris
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','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/20151215/0aba19ab/attachment.html>