[swift-evolution] ternary operator ?: suggestion

[Charles Constant]

I mean, if we can get it across that we're taking a *very common task*, and
making it *less verbose* AND *easier to read*. To me it seems like a
massive win.

> (I guess today actually since it is now 4:30am).

Ha, typical programmer. Get some sleep!


On Thu, Jan 14, 2016 at 1:34 PM, Craig Cruden <ccruden at novafore.com> wrote:

> Thanks, I think I understand now.  I will sleep on it and then come up
> with a new draft of that section tomorrow (I guess today actually since it
> is now 4:30am).
>
>
> On 2016-01-15, at 4:29:12, Charles Constant <charles at charlesism.com>
> 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 *
>>> * }*
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160114/bbf5806c/attachment-0001.html>