[swift-evolution] ternary operator ?: suggestion

Sun Dec 13 09:33:04 CST 2015

It's part of this one:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002056.html

On Sun, Dec 13, 2015 at 4:25 PM, Paul Ossenbruggen <possen at gmail.com> wrote:

> Thanks everyone for the feedback! I will look at it in detail and address
> or incorporate what makes sense for the proposed approach.
>
> Using fully-fledged if/switch-statements as expressions is another
> proposal and discussion (which already exists).
>
>
> can you point me to this?
>
>
> On Dec 13, 2015, at 7:09 AM, Marc Knaup via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Using fully-fledged if/switch-statements as expressions is another
> proposal and discussion (which already exists).
>
> The replacement of the ternary operator should be just syntactic sugar for
> the other proposal to have a shorter version of "let x = if a {} else {}".
>
> Regarding the "then" keyword:
> What about "do"?
>
> let x = if a do b else c
>
> Yes, it reads a bit weird, but as if & switch statements are moving
> towards being expressions already then "do" blocks will likely too.
>
> So the above example would just be another shortcut for
>
> let x = if a { do { b } } else { c }
>
>
>
> On Sun, Dec 13, 2015 at 3:56 PM, Taras Zakharko via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Hi Paul,
>>
>>  what bothers me in your proposal is that you seem to allow only simple
>> expressions. But it is often the case that one needs to have multiple
>> statements to set up the value. For example:
>>
>>   let data = if connection.valid
>>     connection.cached_data
>>   else {
>>     // generate the data again
>>  }
>>
>>  I have been thinking a bit about how to implement this in connection
>> with the idea of code blocks as closures proposal I have posted earlier (
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002056.html).
>> Switch is a bit more complicated, but I think that the existing if
>> statement can be easily turned into expression:
>>
>>    func if_<T>(condition: Bool, then_: (()->T)?, else_: (()->T)?) -> T? {
>>     var result: T?
>>
>>     if condition {
>>         result = then_?()
>>     } else {
>>         result = else_?()
>>     }
>>
>>     return result
>> }
>>
>> the compiler would then translate all if statements into
>>
>>    if_(condition, then_: then block, else_: else block)
>>
>> if the else block is not present, it will be set to nil. In that case the
>> if expression also evaluates to nil. Now, if the if is used as a statement,
>> the above transformation is sufficient and the return value will be
>> optimised away by the compiler. If the expression form is used (i.e. there
>> is an assignment operation), the compiler will forcefully unwrap the result:
>>
>>  let x = if_(condition, then_: then block, else_: else block)!
>>
>> This way, if else block is absent, the program will crash. A bit of
>> tweaking will also generate a useful error message. I am also sure that it
>> is possible to generate a warning (or even an error) at the compile time
>> without too much effort.
>>
>> I think the nice thing about this proposal is that it uses already
>> existing mechanisms in the language and only requires some minimal
>> transformations by the compiler.
>>
>> The switch expression can be approached in a similar way, but would
>> require more compiler magic.
>>
>> Best,
>>
>>  Taras
>>
>> 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
>>
>>
>>
>> On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen at gmail.com> wrote:
>>
>> Implied in using the  “then", if…then…else would aways require “else"
>> when using “then” similar to how “guard" requires “else”. This  will help
>> to make the difference between statements and expressions clear.
>>
>> let x = If cond then X else Y
>>
>> is the full form, where “else" can not be omitted.
>>
>> On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen at gmail.com> wrote:
>>
>>
>>
>> On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> 1. I would really hate to explain to someone when *if* needs a *then* and
>> when it doesn't. That's the sort of inconsistency that shouldn't be added
>> lightly.
>>
>>
>> agreed definitely want to be careful with that. I think with braces
>> meaning statements that differentiation can be made clear. I would
>> certainly start with statements when describing, just as you usually don’t
>> talk about the ternary operator until later.
>>
>> 3. If we can somehow solve all of this, I think I'll be +1 for replacing
>> (A ? B : C) with some sort of (*if* A *then* B *else* C).
>>
>>
>> Yes that would be great.
>>
>>
>> 4. Generally, I wonder how hard would it be for all statements to be
>> usable as expressions? Why didn't Swift go that way from the start?
>>
>>
>> The biggest problem statement is you don’t need to exhaustively specify
>> every outcome:
>>
>> if cond {
>> print(“hello”)
>> }
>>
>> whereas in an expression you have to specify what happens in the else.
>>
>> let say = if cond then “hello” else “goodbye"
>>
>> unless you go seriously off the deep end:
>>
>> let say = if cond then “hello”
>>
>>  “say" then becomes an optional, *shudder*
>>
>>
>>
>>
>> _______________________________________________
>> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151213/9f6ec238/attachment.html>