Daniel Duan Sent from my iPhone
> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution > <[email protected]> wrote: > > > > Daniel Duan > Sent from my iPhone > >> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution >> <[email protected]> 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 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 ignored labels in other Swift constructs (proposed and >> in past versions of Swift, at least) >> 4) Avoids a possible API change for current enums. This is currently legal >> but would not be if the enum case “name” is the entire signature for >> constructing it: >> >> ``` >> enum E { >> case a( a: Int ) >> case b( a: Int ) >> } >> >> let anEmum = E.a( a: 4 ) >> >> >> switch anEmum { >> case .a( let x ) : >> break >> case .b( let x ) : >> break >> } >> >> switch anEmum { >> case .a( let y ) : >> break >> >> case .b( let y ) : >> break >> } >> ``` >> So is this proposal worth creating a breaking change? I don’t think so. it >> would be possible to ignore the associated parameter name, but not the type, >> but that would further confuse case matching, I believe. >> >> I personally don’t see much purpose in having two enum cases with the same >> name if they are always treated as distinct and there is no way to reason on >> the case name. > > Would you say the same for functions? Our opinions differ in what constitute > a "name". In Swift, function names include parameters. Each enum case > declares a function that creates a enum value. That's why it's *more* > consistent for enum to have a similar definition of "name". > > As for pattern matching, number of patterns the number of cases being matched > have a many-to-one relationships. This is true in Swift and many > (Ah, accidentally sent it on my iPhone. My apologies.) … other languages. What you are proposing complicates the rules by making this untrue. We'd have to special-case this feature in our pattern matching algorithm. >> If they are always distinct, then requiring different names eliminates >> unnecessary cognitive load. There is a good reason for functions to have the >> same “name” and different signatures, and there are precedents in many >> languages. >> >> You may disagree, but I believe that enums exist to support reasoning on >> distinct cases and that muddying that by treating the associated value as >> part of the “signature" increases the language “surface area” while adding >> no tangible benefit. >> >> >>>> On Jan 24, 2017, at 2:23 PM, Matthew Johnson via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> >>>> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution >>>> <[email protected]> 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 “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. >>> >>> It sounds like you are missing something. The `bar(a:)` and `bar(b:)` are >>> the full case names. These are *not* the same case. The `bar` shorthand >>> is allowed when there is no ambiguity, however for an enum with both >>> `bar(a:)` and `bar(b:)` there *is* ambiguity and therefore the `bar` >>> shorthand is not allowed. The programmer is required to spell out the full >>> name of the case they wish to match. >>> >>> >>>> >>>> It would still be possible to match on the different types of bar when >>>> needed: >>>> >>>> ``` >>>> enum Foo { >>>> case bar(a: Int) >>>> case bar(b: String) >>>> case notAbar >>>> } >>>> >>>> >>>> switch aFoo { >>>> case .bar( let a: Int) : // matches Ints only >>>> ... >>>> >>>> case .bar( let b: String) : // matches Strings only >>>> ... >>>> } >>>> >>>> switch aFoo { >>>> case .bar : // Matches both cases and that is a good thing >>>> … >>>> >>>> case notAbar: >>>> …. >>>> } >>>> >>>> ``` >>>> >>>>> On Jan 24, 2017, at 5:27 AM, Xiaodi Wu via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> 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 anything. >>>>> >>>>> >>>>>> On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>>> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution >>>>>>> <[email protected]> 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 unambiguous: >>>>>>> >>>>>>> func foo(x: Int, y: Int) {} >>>>>>> >>>>>>> let foo_x_y: (Int, Int) -> () = foo >>>>>>> >>>>>>> so it'd be consistent to continue to allow the same in pattern >>>>>>> references. >>>>>> >>>>>> WRT ambiguity, do we loose the ability to pattern match on the naked >>>>>> case name when two cases share the same base name? >>>>>> >>>>>> enum Foo { >>>>>> case bar(a: Int) >>>>>> case bar(b: String) >>>>>> } >>>>>> >>>>>> switch aFoo { >>>>>> case .bar: // matches both cases >>>>>> break >>>>>> } >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
