[swift-evolution] ternary operator ?: suggestion

[Craig Cruden]

I actually don’t see the two as mutually exclusive…. only two solutions sets that have an intersection where both will work on some scenarios.

The format mentioned below would fail where the resultexpr3 is not a single value (or the last case if the cases were exhaustive without default).  You would have to have some sort of brackets around the cases as you do with switch.  

The following pattern I would expect be problematic due to multiple use of comma within the same block of code (both as a value separator and as a case separator):

result value ? case 1, 2, 5, 7: resultexpr1 … which is apparently a valid pattern according to what I can see in the documentation.

You would still have to include it in a map for more than one value.  

I could see dropping the “cases” clause (multiple) if there were a switch expression like this (was never strongly wed to `cases`.




> On 2016-01-19, at 12:28:38, Chris Lattner <clattner at apple.com> wrote:
> 
>> 
>> On Jan 17, 2016, at 4:52 PM, Craig Cruden via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Chris has said many things about switch as an expression:
>> 
>> "if/else and switch as expressions: These are conceptually interesting things to support, but many of the problems solved by making these into expressions are already solved in Swift in other ways. Making them expressions introduces significant tradeoffs, and on balance, we haven't found a design that is clearly better than what we have so far.”
>> 
>> It is an often requested and often (i.e. every time) rejected…. and has a very high bar to pass before it would be considered.  At a certain point there was a realization that what we were really doing was conditionally mapping from one set to another (whether the set was one value or many) — and we could provide the same functionality plus much more by focusing on a generalized solution (i.e. a design that is clearly better than what we have so far).
>> 
>> The thread/discussion of where this option started to be considered was the 8th of January.
>> 
>> map is an existing function and a mathematical/functional concept which if we allowed for case syntax partial function concept to conditionally map from one domain to another would cover both switch as an expression but in a more generalized way. IMHO.
> 
> As I mentioned up-thread, the most compelling (to me, personally, not speaking for the core team) proposal I’ve seen on this thread so far is to generalize ?: to support pattern matching.  Something like:
> 
> result = value ? case <pattern1>: resultexpr1,
>                  case <pattern2> where <condition>: resultexpr2,
>                  default: resultexpr3
> 
> The idea of generalizing closureexprs to partial functions is interesting, but seems like a non-obvious direction to take things.  By tying this to closure exprs, you’d have to write “x.map {…}” or "{…}()” to get the inline pattern matching.
> 
> The way I look at this is through analogy to if/else and the existing ternary operator.  The "killer feature” of the ternary operator is when the values being selected over are lexically small enough that you’d want to write them inline.  If they are large, then the syntactic weight of if/else isn’t a problem.
> 
> If you extend the same analogy to switch, then the most important cases are when the pattern being matched and the values being processed are lexically small, and have few cases.  We have a lot of syntactic sugar for processing optionals (e.g. if/let, the ?? operator, etc), but ?? for example doesn’t apply to general pattern matching.  With the expression above, for example, you could match on an enum analogously to the ?? operator like this:
> 
> result = someEnum ? case .SomeCase(let x): x, default: y
> 
> If you compare that to a switch statement, I can see how that could be compelling.  OTOH, the larger the expression (the more cases) and the more complex the patterns, the better a switch statement starts to look.
> 
> -Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160119/687079ce/attachment.html>