[swift-evolution] ternary operator ?: suggestion

Thu Jan 14 15:29:12 CST 2016

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/379c6ce3/attachment.html>