[swift-evolution] ternary operator ?: suggestion
Paul Ossenbruggen
possen at gmail.com
Wed Dec 16 16:56:17 CST 2015
Selector Operator Proposal
OK really trying to get this down to its essence, make something that is truly better and more powerful than ternary, and try to keep as much of the advantages of the ternary and hopefully slightly improve the readability. I am calling it the "selector operator". This proposal, does not add a new keyword but adds a new operator. It unifies the concepts of ternary and gives us a new switch like behavior that ternary does not support. The concept is kind of like a train track, with multiple possible directions selectable by one input.
I believe it also addresses the issues that Chris mentioned.
to select from a boolean, a or b:
let a = sel ->> true, false
to select from an enum values as in a switch:
let a = sel ->> .Red: 1, .Green: 2, .Blue: 3
let b = sel ->> .Red: 1, .Green: 2, .Blue: 3, default: 4
let c = sel ->> case .Red: 1, case .Green: 2, case .Blue: 3, default: 4
let d = sel ->> .Red: 1, (sel ->> .Sun: .Yellow, .Moon: .White, .Stars: .Twinkle), .Green: 2, .Blue: 3, default: 4
let e = sel ->> cases: .Red: 1, case .Green: 2, case .Blue: 3, default: 4
a) shows all possible routes handled.
b) shows a default form
c) shows form with case (follows existing switch rules so should be familiar)
d) shows nested form.
e) shows a slight modification to cases label to balance the default, I think balance can be helpful. User can choose concise vs balance.
to select from an integer or any other enumerable type:
let f = sel ->> “A", “B", “C", “D”. “E”, “F”, default: “G”
let g = sel ->> cases: “A", “B", “C", “D”. “E”, “F”, default: “G”
e) shows compact form, must have default because all integers would make for a long list.
f) shows a slight modification to cases label to balance the default, I think balance can be helpful. User can choose concise vs balance.
Advantages:
• This lets ? operator be used only for optionals.
• It pops out in code similar to the ternary operator.
• Slightly improved readability
• Unifies the switch and ternary concepts.
• No new keyword (well, cases: is a minor addition)
• new operator allows us to define how it should be formatted as there is no preconceived notion of how it should be formatted
• By definition it only deals in expressions.
• There is no way it can be confused with statements.
• the interesting syntax would keep people from doing very large expressions in it (Paraphrasing Chris)
• chains well for multiple conditions because of its associativity
• because it is a new concept there is potential to extend it in the future.
Disadvantages:
• May be a slight improvement in readability. Operators have to be looked up if you are not familiar with them.
• New concept that will have to be learned and not present in most C like languages so needs to be learned.
Other Half Baked thoughts:
• Are there other data types that would work with this? Maybe Objects, Dictionaries, Arrays, Ranges enumerations, or Structs (Unions?)
* What would container types look like? Could you call it multiple times on an array? Kind of like a map like behavior where each element goes into the selector operator.
- Paul
> On Dec 16, 2015, at 8:04 AM, J. Cheyo Jimenez <cheyo at masters3d.com> wrote:
>
> Pick is interesting but how do you chain more that one pick/from together?
>
> I thought about just just dropping the if.
>
> let result = bool then 1 else bool then 2 else 3
>
> Or going back to the python style.
>
> let result = 1 where bool else where bool 2 else 3
>
> But you are right, can't beat just having two characters. Specially when the Elvis operator is in every other major c based language.
>
> Perhaps this is just a like ! as a negation character, once you learn the differences then u are set for other languages as well.
>
> It would be nice to be able to bind expressions so that the actual logic of the ?: is not lost.
>
> let result = if (long_boolexpresion,
> longerBoolexoression,
> anotherboolExpression )
> $0 then "a" else $1 && $2 then "b" else "c"
>
>
> On Tuesday, December 15, 2015, Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I think pick…from may address many of the negatives listed by Chris. with the if..then..else approach.
>
>> The closest proposal I’ve seen is the “if cond then value1 else value2” syntax, however that has serious (IMO) problems:
>
>> - It is substantially more verbose than ?:, so much so that it obscures the logic that was trying to be captured. Simple things like this become swallowed in syntax:
>> let x = cond ? 4 : 8
>> let x = if cond then 4 else 8
>
> this suggestion would still be longer, you can’t beat 2 chars. It is shorter than if..then..else though. Not sure there are any good options that can beat the conciseness of the ternary without replacing it with more syntax.
>
> let x = pick cond from 4, 8
>
>>
>> - Because it looks like an if statement, people will end up writing it like:
>>
>> let x = if cond then
>> some_long_expression
>> else
>> some_other_long_expression
>
>> - it only accepts expressions, not statements. The way it is flowed makes it look like a statement.
>> - It is now force indenting a lot, which just looks weird and isn’t precedented in Swift.
>
> By having a new keyword, we can define the format and there is no prior connotation with it.
>
>>
>> When this happens, we now have new problems:
>> - At a glance, it “looks” like an if statement, but it is semantically different.
>
> Since it is a new it will always look like something that handles expressions only.
>
> Also this pick…from statement can be extended to handle switch expressions as well. So it is consistent way to do different expressions based upon an input.
>
> Some downsides:
> new keyword
> no prior history with other programming languages.
>
>
>> On Dec 15, 2015, at 4:31 PM, Paul Ossenbruggen <possen at gmail.com <javascript:_e(%7B%7D,'cvml','possen at gmail.com');>> wrote:
>>
>> Been thinking a bit:
>>
>> Perhaps a new expression is in order. “Pick” this has a form like this. Param is a selector This only allows expressions
>>
>> It has two forms:
>>
>> To replace ternary:
>>
>> let x = pick val from "abc", "cdef"
>>
>> To replace switch expressions. The cases follows existing rules for switch cases.
>>
>> let y = pick val from cases .Red: 1, .Green: 2, .Blue: 3
>>
>> This keeps the notion of expressions and statements quite separate. It avoids syntax confusion. It reads clear. It is fairy concise. It uses a straight forward pattern for both forms of expression.
>>
>> - Paul
>>
>>> On Dec 15, 2015, at 2:06 PM, Charles Constant via swift-evolution <swift-evolution at swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>>>
>>> +1 bigtime for the assignment via Switch proposal
>>>
>>> I think someone here made the argument, I can't remember who, that it would be confusing for beginners. I think exactly the opposite.
>>>
>>> Once a new programmer has learned how to write a normal Switch statement, they'll be able to "leverage" the same concept and map values using the Switch assignment. Some might even try it on their on own, through experimentation, to see if it will work. It's such a pleasant experience when you try something in a language that seems consistent with what you already know, and discover "cool, it works!"
>>>
>>> At the moment, the alternatives are, what, using a dict to map values? trying to shoehorn a corrsponding set of values into an enum? using the existing switch statement (pretty verbose in Swift, due to "let" scope etc)? In my own Swift code, I have encountered situations, frequently, where I wished I had an equivalent to a ternary condition that handled more than two values. Chaining multiple ternary conditions together is unreadable. This proposed Switch assignment expression would take care of that.
>>>
>>> Definitely has my vote!
>>>
>>> _______________________________________________
>>> 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 <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151216/d8a52b80/attachment.html>
More information about the swift-evolution
mailing list