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 two being both
declared as “overloading”. Here’s a function that I would say is overloading
`f(x:y:)`: `func f(x: String, y: String)`.
One of the benefits (as stated in the motivation section of the proposal) is to
make enum case’s name consistent with functions in Swift.
> On Jan 24, 2017, at 3:16 PM, Christopher Kornher <[email protected]> wrote:
>
>>
>> On Jan 24, 2017, at 4:02 PM, Daniel Duan <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>
>> Daniel Duan
>> Sent from my iPhone
>>
>> On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>>
>>>
>>> Daniel Duan
>>> Sent from my iPhone
>>>
>>> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution
>>> <[email protected] <mailto:[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.
>
> I am not proposing a breaking change. I believe that it is the best way to
> handle “overloading” enum names without breaking existing code. I don’t
> believe that this proposal changes any existing logic or rules.
>
> The use of the terms "name” and "signature" is well established in many
> languages. e.g.: https://en.wikipedia.org/wiki/Type_signature
> <https://en.wikipedia.org/wiki/Type_signature> I am trying to use the terms
> in this context.
>
> Sharing a function name (with different signatures) is an aid to
> understanding the purpose of functions and is part of many languages. I do
> not believe that extending the concept to enums is worth the cost, especially
> since it will break existing Swift code.
>
> You are proposing a source breaking change and I do not agree that is is an
> improvement. What is the benefit of this change?
>
>
>>
>>>> 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] <mailto:[email protected]>> wrote:
>>>>>
>>>>>>
>>>>>> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution
>>>>>> <[email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution
>>>>>>> <[email protected] <mailto:[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] <mailto:[email protected]>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> [email protected] <mailto:[email protected]>
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> [email protected] <mailto:[email protected]>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
