In regards to the problem in the root (using if-cases to do membership tests on
option sets), the code given there involving thinking of the OptionSet as a
sequence and iterating over it makes this far less likely to happen. I think
this is a pattern that doesn't need syntax, it needs stdlib
I think you have changed my mind. Virtually everything I want to do can be
achieved by having a closure as an alternative syntax for a function.
Particularly if you could assign to a `var`. You still need extra syntax
for generics and escaping closures.
On Fri, 17 Nov 2017 at 1:45 pm, Slava
On Sat, Nov 18, 2017 at 16:25 Benjamin G
wrote:
> I think because it's not immediately obvious with multiple if statement,
> that they all try to compare the same expression to different patterns.
>
> match exp {
> case 1
> case 2
> }
> vs
> if case 1 = exp
> if
I think because it's not immediately obvious with multiple if statement,
that they all try to compare the same expression to different patterns.
match exp {
case 1
case 2
}
vs
if case 1 = exp
if case 2 = anotherexp
On Sat, Nov 18, 2017 at 10:43 PM, Xiaodi Wu via swift-evolution <
On Sat, Nov 18, 2017 at 3:12 PM, Peter Kamb wrote:
> A high bar for new syntax is fair and expected, and by posting I was
> hoping to maybe find an alternative in the comments here.
>
> But AFAIK there's currently no ability in Swift to:
>
> "Evaluate a *single* control
I understand your point about multiple cases + the halting problem when
applied to the implementation details of switch and pattern matching.
I think where we're missing is that what I'm envisioning would be syntactic
sugar that would be de-sugared into a a line of single-case `if-case`
> alternative to `fallthrough` that would continue matching cases
Yes, that would be interesting to look into. Do you have any references or
remember what the proposed keyword was called? Do any other languages have
this feature?
On Sat, Nov 18, 2017 at 10:53 AM Kevin Nattinger
Robert is quite right--I'm not sure what we're designing for here. There's
a very high bar for introducing new syntax and a distaste for the existing
syntax is not a motivating use case.
On Sat, Nov 18, 2017 at 12:53 PM, Kevin Nattinger via swift-evolution <
swift-evolution@swift.org> wrote:
>
There have been earlier suggestions for an alternative to `fallthrough` that
would continue matching cases; I think that is much more likely to get support
than a whole new construct with only a subtle difference from an existing
one—would that be an acceptable alternative to you?
> On Nov 17,
> On Nov 18, 2017, at 4:42 AM, Peter Kamb wrote:
>
> Thanks for the review.
>
> Motivation is essentially to provide a low-friction way to write `if case /
> if case / if case` statements that are all matching on the same expression,
> much in the same way that `switch`
> On Nov 18, 2017, at 1:44 AM, Jean-Daniel wrote:
>
>
>> …
>>
>> In Ruby, `myObj.name()` is equivalent to `myObj.name`, and either works. In
>> Swift, I don’t see that it’s possible to make both work with Chris’s
>> proposal.
>
> IIUC, the goal is not to make swift
I haven’t spend that much time on thinking about the implications, but at first
sight, it sounds like a sensible idea — maybe even more useful than switch
(whose behavior could be mimicked).
But switch is established, and I don’t see a realistic chance to either replace
it or add a construct
Thanks for the review.
Motivation is essentially to provide a low-friction way to write `if case /
if case / if case` statements that are all matching on the same expression,
much in the same way that `switch` offers a way to write `if / else if /
else` statements against the same expression.
>
Having spent a lot of time with ‘switch’, I don’t understand any of the
motivations or corresponding justifications for this idea. Comments inline:
~Robert Widmann
2017/11/17 15:06、Peter Kamb via swift-evolution のメール:
> ## Title
>
> Add `match` statement as
14 matches
Mail list logo