[swift-evolution] ternary operator ?: suggestion

[Charles Constant]

> I’m not a fan of the concise form, though, and would drop it.

You mean "case*s*", right? I admit I find the syntax is a bit ugly, but if
you have 20 cases to write, it's clearer. I'll bet any money that in day to
day use, if this proposal is accepted, it's the short form that 90% of us
would use.

My vote is that it stay in the proposal.



On Thu, Jan 14, 2016 at 2:32 PM, Thorsten Seitz via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi Craig,
>
> looks good so far!
> I’m not a fan of the concise form, though, and would drop it.
>
> The proposal should define what a partial function is supposed to be.,
> i.e. a function that can check whether an argument is in its domain.
> It should be possible to ask them isDefinedAt() like in Scala. And chain
> them with orElse() and andThen(). That would be really useful!
>
> *let* stdColorCode = {
> *case* .Red: 100
> *case* .Green: 200
> *case* .Blue: 300
> }
>
> // type of stdColorCode: *partial* Color -> Int
> // or maybe: Color => Int
>
> *let* colorCode = stdColorCode.orElse {
> *case* .Yellow: 400
> *case* .Cyan: 500
> *case* .Magenta: 600
> }
>
> *let* x = colorCode(col).orElse(700)
>
> Thinking about it, I have the feeling that it should be possible to force
> exhaustiveness checks somehow.
>
> Maybe like follows:
>
> // Defining a partial function has to be made explicit with a new keyword
> *undefined* in the default clause (or other case clauses)
> // (I briefly thought about reusing „continue“ but that might collide with
> the proposal to make „break“, „continue“ and possibly „return“ to
> // work properly in closures)
> *let* stdColorCode = {
> *case* .Red: 100
> *case* .Green: 200
> *case* .Blue: 300
> *default*: *undefined*
> }
>
> // The following is *not* a partial function (and cannot be asked
> isDefinedAt() or chained).
> // But the compiler would complain if the argument type (here inferred)
> has more cases (just like in a normal switch statement).
> *let* stdColorCode = {
> *case* .Red: 100
> *case* .Green: 200
> *case* .Blue: 300
> *case* .Yellow: 400
> *case* .Cyan: 500
> *case* .Magenta: 600
> }
>
> -Thorsten
>
>
> Am 14.01.2016 um 20:23 schrieb Craig Cruden via swift-evolution <
> swift-evolution at swift.org>:
>
> 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
>
>
>
> _______________________________________________
> 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/78b4d695/attachment.html>