[swift-evolution] ternary operator ?: suggestion

[Dennis Lysenko]

I hate to triple-post, but removing ternary seems similar to the 'removing
c-style for loops' proposal that was recently accepted:
https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md

To quote:
The C-style for-loop appears to be a mechanical carry-over from C rather
than a genuinely Swift-specific construct. It is rarely used and not very
Swift-like.

You could say the same thing about ternary. Rarely used; not very
Swift-like, conflicting with the use of ? for optionals; seems to be
disliked (rationally or irrationally) by many; and in almost all cases you
can achieve the same exact thing, but ostensibly more readable, with a few
extra lines.

On Tue, Dec 15, 2015 at 11:18 AM Dennis Lysenko via swift-evolution <
swift-evolution at swift.org> wrote:

> Also, +1 to removing ?: ternary in general. It does not match the
> atmosphere of Swift. Where you can write:
>
> self.x = a ? b : c
> self.y = a ? d : e
> self.z = a ? f : g
>
> You could just write
>
> if a {
>   self.x = b
>   self.y = d
>   self.z = f
> } else {
>   self.x = c
>   self.y = e
>   self.z = g
> }
>
> Now it's easier to scan for what changes when a is true. With
> if-expressions, this would scale even better to multiple
> conditions/declarations.
>
> On Tue, Dec 15, 2015 at 11:14 AM Dennis Lysenko <
> dennis.s.lysenko at gmail.com> wrote:
>
>> Can we just have if-expressions and Xcode indent if-statements the way
>> that Ruby style guides suggest?
>>
>> let x = if y < 0 {
>> z * z - 4
>> } else {
>> 8
>> }
>>
>>
>> Works fantastically well in Ruby, for me. Looks a bit strange to the
>> untrained eye but that went away for me pretty much the first time I wrote
>> one of these. It's:
>>
>> - More readable than ternary
>> - Not shoehorning complex logic onto one line
>> - All indented to the same indentation level
>>
>> And we don't have the 80-char line delimiter or length limit in Swift,
>> with Xcode also using a slightly smaller font size than most other IDEs, so
>> indentation should not be that much of an issue. Admittedly, ruby style
>> dictates two-space indentation which makes this type of code slightly
>> shallower.
>>
>> On Tue, Dec 15, 2015 at 5:34 AM Al Skipp via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> On 15 Dec 2015, at 06:41, Paul Ossenbruggen via swift-evolution <
>>> 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
>>>
>>>
>>> I’m happy to make use of the ternary operator, but never in a nested
>>> fashion. It looks neat and succinct on first glance, but is quite
>>> impenetrable to read. I don’t think there’s a way to make such nested
>>> expressions easily comprehensible. Nested ‘if/else/then’ expressions will
>>> be equally bewildering.
>>>
>>> On a purely stylistic level I think simple, ‘if/then/else’ expressions,
>>> would have a more Swift vibe to them than the ternary operator. Well, that
>>> would be the case if it didn’t introduce the confusion between expressions
>>> and statements.
>>>
>>> I do still however like the Switch Expressions.
>>>
>>>
>>> I agree. The Switch expression proposal is worth pursuing, it’s
>>> something I’d really like to see in the language. One concern I have is
>>> that it faces the same dilemma of the ‘if’ expression proposal, that is,
>>> how to make the distinction between a statement and an expression
>>> unambiguous?
>>>
>>> Here’s a suggestion, it might be terrible (I’ve not had my third cup of
>>> tea of the morning yet), but how about a different keyword? I know, I feel
>>> guilty for the suggestion already, but here it is:
>>>
>>> switch == statement
>>> match == expression
>>>
>>> The syntax you (@Paul) have already suggested for the feature wouldn’t
>>> change, but instead of ‘switch’, it’d use the ‘match’ keyword for the
>>> expression form. Good, bad, terrible? What do people think?
>>>
>>> Al
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151215/e1ae45d0/attachment.html>