[swift-evolution] ternary operator ?: suggestion
possen at gmail.com
Sat Jan 9 19:16:14 CST 2016
> On Jan 9, 2016, at 4:09 PM, Charles Constant <charles at charlesism.com> wrote:
> More fiddling... any takers for "on"?
> Yes, this is partly a last ditch attempt trying to revive my earlier proposal :) It still irks me that we'd have a switch using the colon two different ways. Also my last suggestion had the order reversed ( i.e.: "val =test" but then "==test val" in the cases ) which is irritating.
> let str = boo ?
> "yes" on true :
> "no" on false
> let num = color ?
> 100 on .Red :
> 200 on .Green :
> 300 on .Blue :
> -1 on default
This does have some nice properties, like more compact than “case", don’t need the word “case" out front and a separator. Having the order the other way though I think would not work. You would need t support long expressions etc, so I don’t think having it reversed would be popular. Perhaps something like this
let num = color ?
.Red to 100 :
.Green to 200 :
.Blue to 300 :
default to -1
I like some of it but, I still want to put the colons in-between the case labels. This syntax would be seen as too different from something we already have with the “case label: expression” syntax. Maybe seen as “different but not better"
Meanwhile I have been learning Scala. The unary function, partial functions, and pattern matching stuff looks cool.
> The more verbose forms will be easier to learn, I suppose, but it's also nice, when you have a long list of things like this, to keep things as json-y as possible. Granted if we use the short version, there's developers who will flame anyone listening for doubling down on the evil ternary.
> On Fri, Jan 8, 2016 at 11:18 AM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
> On Jan 7, 2016, at 12:10 AM, Paul Ossenbruggen <possen at gmail.com <mailto:possen at gmail.com>> wrote:
> > Just a few hopefully quick questions:
> > Do you have any thoughts on supporting two forms? Like the compact form where case and default are not present, and the more formal switch like form?
> Adding two forms seems very unlikely to be accepted - even adding one form is unclear :-)
> > Do you have any specific reasons to not support “where”? Is it just to keep it simple and when we need more complexity use the statement form?
> I don’t have a strong objection to where, other than trying to keep things simple. It is reasonable to argue that removing “where” makes things more complex by making the expression *different* from the statement though.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution