I think trying to mix statements and expressions will definitely lead to a more complex solution I have tried going down that path. The second and third approaches in my email last night attempt to straddle the line between more cryptic ? syntax of the ternary and the if, switch, approach.
I don’t have an aversion to the ternary just because it is in C. In fact, when I first started writing the proposal, it was intending to keep it exactly as is, but it became clear that there would be two different forms, and that what I was proposing would be better than ternary. I think my proposal addresses many of the shortcomings of the ternary and provides more capability. Just to list a few, but in my proposal I have a much more exhaustive list: • it is hard to tell when a ternary begins and ends, especially when nested. • It is not until you get to the question mark that you realize it is a ternary. • it is hard to read something like this x = y == z ? “A”, “B” does the == get read first or second. With my proposal all these issues are addressed which makes it better than ternary. - Paul > On Dec 22, 2015, at 10:14 AM, Craig Cruden via swift-evolution > <swift-evolution@swift.org> wrote: > > IMHO, I think the issue is that (at least in my case) we may be trying to > create expression versions of “if” and “switch” (multi-line) and not are > trying to create them in such a way as to keep statements and expressions as > separate syntax / keywords…. which is leading to a more cryptic solution. > Not being a compiler guy, I have no idea what the complication is with > regards to why the syntax has to be different. > > Or we are trying to create new syntax for a simple C ternary because > somewhere along the line some people have an aversion to syntax just because > C uses it. > > Those two are combining in an unholy alliance :o > > Craig > >> On 2015-12-23, at 1:07:26, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I think this is a good point. We definitely want to keep the boolean ternary >> operator compact for the simple cases, and that may be at odds with a >> general switch expression (with multi-case pattern match). >> >> Jordan >> >> >>> On Dec 22, 2015, at 10:03 , Thorsten Seitz via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> Sorry, but I find all these very unreadable. >>> >>> IMO trying to create one-line switch expressions is a non-goal as I would >>> always write switch expressions in multiple lines, one per case. Anything >>> else I personally consider unreadable. >>> >>> -Thorsten >>> >>> Am 22.12.2015 um 09:11 schrieb Paul Ossenbruggen via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >>> >>>> All, >>>> >>>> I have continued work on my proposal. I am trying to gauge whether people >>>> feel that this syntax which is currently in the proposal is better or >>>> worse than the last two variations. The current proposal syntax: >>>> >>>> let a = ?(x == y: a, b) >>>> let b = ?(colorEnum : Red: 0xFF0000, .Green: 0x00FF00, .Blue: 0x00000FF, >>>> default: 0xFFFFFF) >>>> let c = ?(pickOne : “A”, “B”, “C:, default: “Z”) >>>> >>>> The preceding is the unified ?( operator approach and is the closest to >>>> the existing ternary. but expands its capabilities to support more types >>>> of control than just bool. It is the most concise and adds no new >>>> keywords. It determines the kind of expression based upon the format >>>> inside the braces. The next version is the full keyword approach which has >>>> the same capabilities but separates each kind out: >>>> >>>> let a = if(x == y then "A" else "B") >>>> let b = switch(colorEnum then .Red: 0xFF0000, .Green: 0x00FF00, .Blue: >>>> 0x00000FF, default: 0xFFFFFF) >>>> let c = select(pickone then "A", "B", "C", default: "Z”) >>>> >>>> or to avoid a new keyword and be slightly more concise. This one is the >>>> hybrid approach: >>>> >>>> let a = if(x == y : "A" else "B") >>>> let b = switch(colorEnum : .Red: 0xFF0000, .Green: 0x00FF00, .Blue: >>>> 0x00000FF) >>>> let c = select(pickone : "A", "B", "C", default: "Z") >>>> >>>> Note that the use of parenthesis outside the entire expression in these is >>>> to emphasize that these are expressions, can be read almost like a regular >>>> function, they serve to group the entire expression, and they would be >>>> required around the full expression only the leading keyword is outside. >>>> This will disambiguate it from the statement form. Braces are for >>>> statements and parenthesis for expressions. Putting the “then”and “else” >>>> part inside the parens also avoids the problem of “then” with the >>>> following format: >>>> >>>> x = if cond then A else B >>>> >>>> With this we would have support “then” in the “if" statement form and it >>>> is hard to tell it from the statement form. By putting it in parenthesis, >>>> we can put whatever we want in there. >>>> >>>> The advantage of the second or third approach is the syntax would be >>>> custom to each kind so additional checking could be performed to ensure it >>>> is correct for the keyword provided. The keywords would be context >>>> sensitive so may not interfere with other uses of it. >>>> >>>> These last two possibilities may address some of the issues that Jordan >>>> Rose brought up…the first is the double colon, for the separator and for >>>> the cases. The issue he mentioned second is that he did not feel my >>>> proposal addressed any of the problems with the ternary, and third he >>>> wants to keep the ? just for optionals. If the colon to separate the >>>> control, in the last one is not good, I am open to suggestions for other >>>> separators, but keep in mind, that goes even further from the ternary >>>> which may or may not be a good thing. >>>> >>>> I think I would be happy with any of these. If the consensus is that >>>> either of the last two are preferable, I will rewrite the proposal with >>>> that in mind. Please let me know if you have any questions or have other >>>> suggestions. >>>> >>>> Thanks, >>>> - Paul >>>> >>>> For latest version of proposal and see Alternatives Considered section for >>>> more details on this: >>>> https://github.com/possen/swift-evolution/blob/master/proposals/0024.md >>>> <https://github.com/possen/swift-evolution/blob/master/proposals/0024.md> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
