Re: [swift-evolution] [draft] Compound Names For Enum Cases

I'm also +1 on this, wanted this for a long time :) - Dennis > On Feb 2, 2017, at 2:42 PM, Adrian Zubarev via swift-evolution > wrote: > > Great, thanks. Love it :) > > +1 > > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 2. Februar 2017 um 14:39:43,

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Great, thanks. Love it :) +1 --  Adrian Zubarev Sent with Airmail Am 2. Februar 2017 um 14:39:43, Daniel Duan (dan...@duan.org) schrieb: This has been answered in various forms in the thread. Short answer: yes. On Feb 2, 2017, at 2:05 AM, Adrian Zubarev

Re: [swift-evolution] [draft] Compound Names For Enum Cases

This has been answered in various forms in the thread. Short answer: yes. > On Feb 2, 2017, at 2:05 AM, Adrian Zubarev > wrote: > > Is that correct that this proposal will add some sort of overloading enum > cases by different labels? > > enum Foo { >

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Is that correct that this proposal will add some sort of overloading enum cases by different labels? enum Foo { case foo(a: Int) case foo(a: Int, b: Int) } Is Foo a valid enum after this proposal? --  Adrian Zubarev Sent with Airmail Am 19. Januar 2017 um 19:37:50, Daniel Duan via

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Would using arbitrary label names in statements like `case .foo ( let bar )` still work? See my example below? There is some code that does this, but it can be fixed with a simple string replacement for nearly all cases, I would think. > On Jan 24, 2017, at 8:10 PM, Xiaodi Wu via

Re: [swift-evolution] [draft] Compound Names For Enum Cases

No code would be broken. Like functions, case `bar(a:)` can be referred to as `bar` as long as there is no ambiguity. No existing code can have more than one case named bar. On Tue, Jan 24, 2017 at 19:17 Christopher Kornher wrote: > Sorry for not connecting the dots…yet another

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Sorry for not connecting the dots…yet another example of why we need a better way to handle long discussions :) …and the dangers of multitasking, perhaps… I guess that this shows that having multiple cases with the same name, distinguished by the type of associated value, is possible without

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 24, 2017, at 3:51 PM, Christopher Kornher wrote: > >> >> On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> I'm now confused who is arguing for what. Enums cases cannot have the

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Yes, but *this* proposal is precisely to make the label part of the name. On Tue, Jan 24, 2017 at 17:51 Christopher Kornher wrote: > On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I'm now confused who is arguing for what.

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 24, 2017, at 4:24 PM, Xiaodi Wu via swift-evolution > wrote: > > I'm now confused who is arguing for what. Enums cases cannot have the same > name. As far as I'm aware, this proposal does not seek to change that. Each > case must still be unique. It only

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Just to be clear (so may previous point may make more sense), the “name” in the function `func f(x: Int, y: Int) {}` is `f(x:y:)`. The name of `f(a: Int, b: Int) {}` does *not* share a name with the previous function. That’s what I refer to when I talk about names. I would not consider these

Re: [swift-evolution] [draft] Compound Names For Enum Cases

I'm now confused who is arguing for what. Enums cases cannot have the same name. As far as I'm aware, this proposal does not seek to change that. Each case must still be unique. It only changes whether labels are regarded as part of the name or part of the associated type. On Tue, Jan 24, 2017

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 24, 2017, at 4:02 PM, Daniel Duan wrote: > > > > Daniel Duan > Sent from my iPhone > > On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution > > wrote: > >> >> >> Daniel Duan >> Sent from my

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Daniel Duan Sent from my iPhone > On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution > wrote: > > > > Daniel Duan > Sent from my iPhone > >> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution >> wrote: >>

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Daniel Duan Sent from my iPhone > On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution > wrote: > > I agree that this rule would be consistent with the handing of Swift > function signatures, but my proposal is self-consistent and: > > 1) It is

Re: [swift-evolution] [draft] Compound Names For Enum Cases

I agree that this rule would be consistent with the handing of Swift function signatures, but my proposal is self-consistent and: 1) It is more powerful, matching on the case name or not as required. 2) Is consistent with existing switches that ignore associated values 3) Is constant with

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution > wrote: > > Your example is only has only one case, which is not typical. Perhaps I am > missing something, but the only reason that I can imagine for having a case > with multiple ways to

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Your example is only has only one case, which is not typical. Perhaps I am missing something, but the only reason that I can imagine for having a case with multiple ways to “construct” it is to have all variants of the case to match. If you don’t want them to match, use a different case name.

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Great suggestion. Done. > On Jan 24, 2017, at 5:07 AM, David Hart via swift-evolution > wrote: > > Ok, sounds logical. Might be worth adding that info to the proposal to make > it clear how ambiguity plays out. > >> On 24 Jan 2017, at 13:27, Xiaodi Wu

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Ok, sounds logical. Might be worth adding that info to the proposal to make it clear how ambiguity plays out. > On 24 Jan 2017, at 13:27, Xiaodi Wu wrote: > > I would imagine it would be logical to have it work just like it does now > with functions. If case bar is

Re: [swift-evolution] [draft] Compound Names For Enum Cases

I would imagine it would be logical to have it work just like it does now with functions. If case bar is distinct, then that should still work, but if bar is "overloaded," then case bar should be invalid for ambiguity. Seems fine to me, shouldn't break any existing code and therefore we don't lose

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution > wrote: > > We're not terribly principled about this right now with non-pattern > declaration references. You can still reference an unapplied function by its > base name alone without its labels, if it's

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Sent from my iPad > On Jan 23, 2017, at 8:48 PM, Karl Wagner wrote: > > >>> On 24 Jan 2017, at 01:03, Joe Groff via swift-evolution >>> wrote: >>> >>> On Jan 23, 2017, at 4:00 PM, Matthew Johnson wrote:

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On 24 Jan 2017, at 01:03, Joe Groff via swift-evolution > wrote: > >> >> On Jan 23, 2017, at 4:00 PM, Matthew Johnson > > wrote: >> >> >>> On Jan 23, 2017, at 5:52 PM, Joe Groff >>

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 23, 2017, at 6:03 PM, Joe Groff wrote: > > >> On Jan 23, 2017, at 4:00 PM, Matthew Johnson > > wrote: >> >> >>> On Jan 23, 2017, at 5:52 PM, Joe Groff >> > wrote:

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 23, 2017, at 5:52 PM, Joe Groff wrote: > >> >> On Jan 23, 2017, at 3:49 PM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On Jan 23, 2017, at 3:32 PM, Joe Groff via swift-evolution >>

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 23, 2017, at 4:00 PM, Matthew Johnson wrote: > > >> On Jan 23, 2017, at 5:52 PM, Joe Groff > > wrote: >> >>> >>> On Jan 23, 2017, at 3:49 PM, Matthew Johnson >>

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 23, 2017, at 3:49 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Jan 23, 2017, at 3:32 PM, Joe Groff via swift-evolution > > wrote: > >> This looks pretty good! It might be worth

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Sent from my iPad > On Jan 23, 2017, at 3:32 PM, Joe Groff via swift-evolution > wrote: > > This looks pretty good! It might be worth calling out explicitly that > matching a payloaded case by name alone still works, e.g.: > > enum Foo { case foo(Int), bar(x:

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Added to the “Source Compatibility” section https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/-Normalize-Enum-Case-Representation.md > On Jan 23, 2017, at 1:32 PM, Joe Groff wrote: > > This looks pretty good! It might be worth calling

Re: [swift-evolution] [draft] Compound Names For Enum Cases

I’ve incorporated feedbacks from this thread. Rendered: https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/-Normalize-Enum-Case-Representation.md

Re: [swift-evolution] [draft] Compound Names For Enum Cases

This looks pretty good! It might be worth calling out explicitly that matching a payloaded case by name alone still works, e.g.: enum Foo { case foo(Int), bar(x: Int) } switch Foo.foo(0) { case .foo: break case .bar(x:): break } -Joe > On Jan 23, 2017, at 11:38 AM, Daniel Duan

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 22, 2017, at 8:30 AM, Tony Allevato via swift-evolution > wrote: > > Which is another reason we should be auto-deriving Equatable. > > Couldn't variation generics help here? If someone wanted to capture the whole > argument list as a single tuple, we could

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 22, 2017, at 11:26 AM, Matthew Johnson wrote: > > >> On Jan 22, 2017, at 3:51 AM, Robert Widmann via swift-evolution >> > wrote: >> >> Sure. One of the first gadgets I wrote was a way of

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 22, 2017, at 3:51 AM, Robert Widmann via swift-evolution > wrote: > > Sure. One of the first gadgets I wrote was a way of destructuring an array > into a familiar cons-list kind of enum > (https://github.com/typelift/Basis/blob/master/Basis/Array.swift#L9

Re: [swift-evolution] [draft] Compound Names For Enum Cases

This would be a real loss . Another nice thing we would be losing is tuple field labels *after* matching: if case let .bar(a) = Foo.bar(x: Int, y: Int) { doThings(with: a.x, a.y) } Keeping them means we have the create a special (reverse)splatting rule for pattern matching. I can see a few

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Which is another reason we should be auto-deriving Equatable. Couldn't variation generics help here? If someone wanted to capture the whole argument list as a single tuple, we could require that they do it as a parameter pack? It's essentially the inverse of the tuple splat already mentioned in

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Implementing equality would be made tedious again if we lose this. ``` enum Jams : Equatable { case dmsr(Bool) case kiss(Bool, Bool) case pheromone(Int, Bool, Int) public static func ==(lhs:Jams, rhs:Jams) -> Bool { switch (lhs, rhs) { case let (.dmsr(left),

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Sure. One of the first gadgets I wrote was a way of destructuring an array into a familiar cons-list kind of enum (https://github.com/typelift/Basis/blob/master/Basis/Array.swift#L9) which you use something like this with other non-trivial enums

Re: [swift-evolution] [draft] Compound Names For Enum Cases

FWIW, in all public Github repos with 5k+ stars whose language gets recognized as “Swift”, 576 enum cases has associated values and among them 55 has 2 values or more. After some very casual grepping I didn’t find a lot of usage of this particular pattern. Care to share some examples, Robert?

Re: [swift-evolution] [draft] Compound Names For Enum Cases

I find myself doing this a lot, but maybe my problems are just more Algebra-shaped than most. That said, I appreciate this cleanup and lean +1 (because you mentioned a way to partly keep this behavior). ~Robert Widmann 2017/01/19 18:14、Joe Groff via swift-evolution

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 19, 2017, at 11:06 PM, Rien wrote: > > Would this be allowed ? > > enum foo { > case bar(num: Int) > case bar(str: String) > case vee(val: Bool) > } > This is certainly an option…personally I think it's a little unconventional. It's require new syntax for

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Would this be allowed ? enum foo { case bar(num: Int) case bar(str: String) case vee(val: Bool) } If so, would this still be allowed ? var a: foo = ... switch a { case vee: ... case bar: ... } Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github:

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 19, 2017, at 2:29 PM, Joe Groff via swift-evolution > wrote: > > >> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution >> wrote: >> >> This looks totally reasonable to me. A couple of comments: >> >> 1) Because

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 19, 2017, at 2:58 PM, Daniel Duan wrote: > > >> On Jan 19, 2017, at 2:29 PM, Joe Groff wrote: >> >>> >>> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution >>> wrote: >>> >>> This looks totally reasonable

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 19, 2017, at 4:58 PM, Daniel Duan via swift-evolution > wrote: > > >> On Jan 19, 2017, at 2:29 PM, Joe Groff > > wrote: >> >>> >>> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 19, 2017, at 2:29 PM, Joe Groff wrote: > >> >> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution >> > wrote: >> >> This looks totally reasonable to me. A couple of comments: >> >> 1)

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution > wrote: > > This looks totally reasonable to me. A couple of comments: > > 1) Because this proposal is breaking the link between the associated value of > an enum case and tuple types, I think it

Re: [swift-evolution] [draft] Compound Names For Enum Cases

This looks totally reasonable to me. A couple of comments: 1) Because this proposal is breaking the link between the associated value of an enum case and tuple types, I think it should spell out the rules that switch statements will use when matching an enum value against a a case with an

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Obvious +1. Since enum cases with payloads are essentially static factory functions and you can get references to them just like any other function, those references should follow the same rules as a regular function. On Thu, Jan 19, 2017 at 10:37 AM Daniel Duan via swift-evolution <

[swift-evolution] [draft] Compound Names For Enum Cases

Hi all, Here’s a short proposal for fixing an inconsistency in Swift’s enum. Please share you feedback :) (Updating/rendered version: https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/-Compound-Names-For-Enum-Cases.md