[swift-evolution] ternary operator ?: suggestion

Thu Jan 14 16:08:16 CST 2016

> I think you could say something along these lines... The standard
conditional value in the ternary operator is being replaced with an
inserted value that can be of any equatable (possibly comparable) type.
While the "true:false" portion of the ternary operator will be replaced
with case:value pairs of which will be used to compare the case to the
inserted value and return the value from the matched pair.

That seems a lot more accurate than mine. For the "motivation" section it's
a bit intimidating though (not that my description was better). It would be
nice if we found a description that a five year could understand. Like
"It's a very common task to write a 'switch' statement just to choose a
value to assign to one variable." Ugh, that's probably still to convoluted
:(

I suppose I'm concerned that someone skimming the document won't pay enough
attention to really grok the proposal. That's generally what I do.

On Thu, Jan 14, 2016 at 1:46 PM, Jo Albright <jo2co.me at gmail.com> wrote:

> I think you could say something along these lines... The standard
> conditional value in the ternary operator is being replaced with an
> inserted value that can be of any equatable (possibly comparable) type.
> While the "true:false" portion of the ternary operator will be replaced
> with case:value pairs of which will be used to compare the case to the
> inserted value and return the value from the matched pair.
>
> Jo
>
> Sent from my iPhone
>
> On Jan 14, 2016, at 4:29 PM, Charles Constant via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> That was my attempt, maybe a poor one, at expressing what we're trying to
> do. I guess another way to express it is that we're "mapping" but only
> mapping one possible value.
>
> Maybe "domain" isn't the best choice of words, but fwiw I meant, say for
> the "ternary expression":
>
> let result = boo ? "it worked" : "it failed"
>
> I was thinking that what we're doing is kind of this:
>
> Domain A is "Boolean Values", which can be: "true" or "false"
> Domain B is "Status Strings", which can be "It worked" or "it failed"
>
> So our ternary maps the states of our bool to the states of our strings,
> and uses the value as a key. Does that make sense? Well, maybe not :)
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Jan 14, 2016 at 1:21 PM, Craig Cruden <ccruden at novafore.com>
> wrote:
>
>> Thanks,
>>
>> - the need to use a value from one domain, as a "key" to another is very
>> common. The ternary is a special case of this, and for all it's flaws, it's
>> a very popular expression in multiple languages
>>
>>
>> This one I am not quite sure what you are saying with this one - can you
>> expand it a bit so I understand the key selling point?  The rest of the
>> points I understand.
>>
>> On 2016-01-15, at 4:16:56, Charles Constant <charles at charlesism.com>
>> wrote:
>>
>> Hi Craig,
>>
>> Well done, what you wrote looks pretty good to me. I had no trouble
>> understanding the proposal. It's a good length, too - I think the shorter
>> we can make it, the more appealing it is.
>>
>> The only section that I think needs improvement is "Motivation." I think
>> we could sell it better. I know when I've read some of the other proposals,
>> I do it in fairly cursory way.
>> "Motivation" could be clearer for those of our peers who haven't followed
>> the thread.
>>
>> The motivation, from my point of view:
>> - the need to use a value from one domain, as a "key" to another is very
>> common. The ternary is a special case of this, and for all it's flaws, it's
>> a very popular expression in multiple languages
>> - using the existing "switch" to do this is bloated (more so in Swift
>> because you have to declare the variable before the switch statement)
>> - using the existing "switch" to do this is less safe, because unrelated
>> code can be inserted in the case statements
>> - current alternatives to "switch" aren't good (e.g.: using a Dict has
>> quirks that add the cognitive load)
>> - this new "map" method can make code less verbose, easier to read, and
>> safer
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Jan 14, 2016 at 11:23 AM, Craig Cruden <ccruden at novafore.com>
>> wrote:
>>
>>> Paul,
>>>
>>> I tried to put my understanding on the latest proposal option into a
>>> draft on github (instead of my usual BitBucket repo).
>>>
>>> Take a look at it and see if there is anything useable.
>>>
>>>
>>> https://github.com/cacruden/swift-evolution/blob/master/proposals/0000-Pattern-Matching-Partial-Function.md
>>>
>>> Craig
>>>
>>> On 2016-01-11, at 14:17:09, Craig Cruden <ccruden at novafore.com> wrote:
>>>
>>> Ignore the last comment - tired and mistaken. :p
>>>
>>>
>>> On 2016-01-11, at 14:16:01, Craig Cruden <ccruden at novafore.com> wrote:
>>>
>>> I just realized “cases” probably is not needed - if it see’s a comma
>>> after case but before “:” then it is the concise form.
>>>
>>> If the switch / case can do that , the partial function case should be
>>> able to do the same thing.
>>>
>>>
>>> On 2016-01-11, at 13:23:19, Craig Cruden <ccruden at novafore.com> wrote:
>>>
>>> I have thought about it a bit more and I think this would cover all the
>>> cases that interest me (in addition to others needs for a little more
>>> conciseness on the most simple case).
>>>
>>> I also think we need to be clear that the “case” (or cases) and
>>> “default” are is really just a partial function which in it’s entirety is
>>> really just a complete function for used wherever a complete function
>>> (exhaustive) can be passed (e.g. reduce, filter, etc.) - otherwise they
>>> might get confused on why we are adding it to “map”.
>>>
>>> The optional where clause should also be part of the case clause as part
>>> of the proposal.
>>>
>>> There would be no need for statement based “fallthrough”.
>>>
>>> You mentioned your proposal….  have you drafted a formal proposal draft?
>>>
>>>
>>>
>>> On 2016-01-10, at 12:41:03, Paul Ossenbruggen via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> I agree that it would be really useful to keep things concise. I am
>>> going to suggest again an idea I had in the past, it is also in my
>>> proposal, which might work well for this problem. This might address the
>>> verbosity of the “case” and at the same time make it obvious we are dealing
>>> with a switch expression. So both would be valid:
>>>
>>> * let num = color.map {*
>>>
>>> * cases .Red: 100, *
>>> * .Green:  200, *
>>> * .Blue: 300*
>>> * default: -1 *
>>> * }*
>>> * let num = color.map {*
>>> * case .Red: 100*
>>> * case .Green:  200 *
>>> * case .Blue: 300*
>>> * default: -1 *
>>> * }*
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160114/4b4b8ed9/attachment.html>