Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-10077] Switching over duplicate enum case names won't compile #52479

Open
swift-ci opened this issue Mar 11, 2019 · 9 comments
Open

[SR-10077] Switching over duplicate enum case names won't compile #52479

swift-ci opened this issue Mar 11, 2019 · 9 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself declarations Feature: declarations enum cases Feature → enums: Enum cases enum Feature → type declarations: Swift enumeration declarations overloading Feature: Overloading symbol names pattern matching Feature: pattern matching patterns Feature: patterns swift 5.9 type checker Area → compiler: Semantic analysis unexpected error Bug: Unexpected error

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Mar 11, 2019

Previous ID SR-10077
Radar None
Original Reporter xavier.lowmiller (JIRA User)
Type Bug
Additional Detail from JIRA
Votes 12
Component/s Compiler
Labels Bug
Assignee @slavapestov
Priority Medium

md5: 11bc61add2da06bf28b3399dd2617f81

Issue Description:

In Swift 4.2 (Xcode 10.1) and 5.0 (Xcode 10.2 beta 4), it's legal to define multiple identical enum cases as long as their associated value is different:

enum PictureImport {
    case add(image: UIImage)
    case add(data: Data)
}

This, however, leads to compile errors when switching:

func importImage(_ importedImage: PictureImport) {
    switch importedImage {
    case .add(image: let image): // Error: Tuple pattern element label 'image' must be 'data'
        // ...
    case .add(data: let data):
        // ...
    }
}

(Maybe related to #49402)

@belkadan
Copy link
Contributor

I don't think we actually finished implementing this. CodaFi (JIRA User), @slavapestov?

@slavapestov
Copy link
Member

slavapestov commented Mar 14, 2019

Yeah, there are a few problems. Member reference expressions don't work either:

enum E {
  case foo(bar: ())
  case foo(baz: Int)
}

E.foo(bar: ())
E.foo(bar: 3) // error

Also we don't allow overloading on type; I think we should since we want these to behave like functions:

enum E {
  case foo(baz: String)
  case foo(baz: Int) // error
}

Finally, the more serious problem here is that for resilient enums, the mangling for the case ordinal symbol does not include argument labels. It mangles the interface type without labels, which is of the form (Enum.Type) -> (Payload) -> Enum. The correct mangling would omit the first and last components of the interface type since they don't matter, but it would include argument labels.

Doing this without breaking ABI will require adding a special attribute or build flag (which is in turn carried over to the parsable interface) to the standard library and overlays. All new code would build with the new mangling. We should fix this soon even if we don't fix the redeclaration checking or other problems, otherwise we won't be able to implement this stuff at all.

@tkrajacic
Copy link

@slavapestov has any work been done on this? It seems pretty bad that I can write perfectly fine enums where the case label is the same, but on switching it breaks down completely.

struct Handler {}
struct HandlerConfig {}


enum Config {
    case `default`(handler: (String) -> Handler, other: (String) -> Handler)
    case `default`(handlerConfig: HandlerConfig)
}


func initialize(config: Config) {
    switch config {
    // These are the cases that fixit adds!
    case .default(handler: let handler, other: let other):
        // Error: Tuple pattern has the wrong length for tuple type '(handlerConfig: HandlerConfig)'
        ()
    case .default(handlerConfig: let handlerConfig):
        ()
    }
}

This makes me cry

@swift-ci
Copy link
Collaborator Author

Comment by Marco Boerner (JIRA)

Has any progress been made @slavapestov, @belkadan, CodaFi (JIRA User)? It's a long awaited for feature 🙂

@swift-ci
Copy link
Collaborator Author

Comment by Luigi Trevisi (JIRA)

Hello @slavapestov is there any update on this bug? 🙂

@theblixguy
Copy link
Collaborator

I have a fix for what Slava mentions, it just needs one final push then it can be merged - #31936

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@tobischw
Copy link

tobischw commented Jul 21, 2022

This bug still seems to be around (since 2019). Any plans to fix it eventually?

@KuhlTime
Copy link

Any updates on this?

@AnthonyLatsis AnthonyLatsis added type checker Area → compiler: Semantic analysis enum Feature → type declarations: Swift enumeration declarations swift 5.9 unexpected error Bug: Unexpected error enum case overloading enum cases Feature → enums: Enum cases pattern matching Feature: pattern matching patterns Feature: patterns labels May 4, 2023
@AnthonyLatsis AnthonyLatsis added overloading Feature: Overloading symbol names declarations Feature: declarations and removed enum case overloading labels May 16, 2023
@r3econ
Copy link

r3econ commented Mar 16, 2024

Any updates on the issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself declarations Feature: declarations enum cases Feature → enums: Enum cases enum Feature → type declarations: Swift enumeration declarations overloading Feature: Overloading symbol names pattern matching Feature: pattern matching patterns Feature: patterns swift 5.9 type checker Area → compiler: Semantic analysis unexpected error Bug: Unexpected error
Projects
None yet
Development

No branches or pull requests

9 participants