[swift-evolution] ternary operator ?: suggestion

[Marc Knaup]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151213/3e977188/attachment.html>