[swift-evolution] ternary operator ?: suggestion
Paul Ossenbruggen
possen at gmail.com
Sun Dec 13 13:17:22 CST 2015
> 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 {}”.
This is the expression vs statement debate and whether they can be made the same. I don’t think they can easily see my response to Taras.
>
> 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 }
>
>
This is a possibility if “then” is deemed to useful in other contexts and the feedback is that we don’t want another keyword. I like the readability of “then"
>
> On Sun, Dec 13, 2015 at 3:56 PM, Taras Zakharko via swift-evolution <swift-evolution at swift.org <mailto: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 <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 <mailto: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 <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 <mailto: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 <mailto:possen at gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>>> On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/99a1bd78/attachment.html>
More information about the swift-evolution
mailing list