[swift-evolution] ternary operator ?: suggestion

[J. Cheyo Jimenez]

+1 on this.

"This is also why I think I expressions and statements should be different.
Trying to make statements into expressions will lead to a lot of
complications and will lead to harder to understand programming model. Not
saying it is impossible but definitely much more involved. "




On Sunday, December 13, 2015, Paul Ossenbruggen via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi Taras,
>
> I understand your point, if you need to do what you are suggesting, which
> is multiple statements which, eventually resolve to one result, You would
> still be able to do that with the existent switch statement. The expression
> syntax should be thought of as more functional in that you don’t have side
> effects and other processing in it. It simply flows through and produces
> one answer as any other expression would.
>
> Another way to think of it, is if you think you should be able to do it
> with a ternary operator, then you should be able to do it with the proposed
> solution.
>
> On Dec 13, 2015, at 6:53 AM, Taras Zakharko <taras.zakharko at googlemail.com
> <javascript:_e(%7B%7D,'cvml','taras.zakharko at googlemail.com');>> 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)
>
>
> Your if_ func is interesting, I am going play with this a bit.
>
> 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:
>
>
> Unless I am misunderstanding your suggestion, I experimented with leaving
> “else” off resulting in an optional if not all cases are handled. This I
> think makes it confusing because now you have to deal with an optional,
> optionals usually mean more conditionals later. I want to know at the end
> of the expression that my variable was properly set in all cases. It seems
> like trouble to deal with the possibility that you don’t know the result of
> the expression at the end of the expression, which is essentially what you
> have with the nil result and everything after that has to deal with that
> optional. Doesn’t that mean that all if expressions would return some sort
> of optional?
>
>
>  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.
>
>
> It would be preferred to not have runtime errors or compiler errors to
> deal with. My proposal, by guaranteeing a result, would not have that
> issue. This is also why I think I expressions and statements should be
> different. Trying to make statements into expressions will lead to a lot of
> complications and will lead to harder to understand programming model. Not
> saying it is impossible but definitely much more involved.
>
>
> 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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','possen at gmail.com');>> wrote:
>
>
>
> On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','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
> <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/20151213/da5cf061/attachment.html>