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

Jump to bottom

[SR-5333] Enums without associated values can still have associated values extracted #47907

Open
ZevEisenberg opened this issue Jun 29, 2017 · 10 comments
Open

[SR-5333] Enums without associated values can still have associated values extracted #47907

ZevEisenberg opened this issue Jun 29, 2017 · 10 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@ZevEisenberg
Copy link
Contributor

Previous ID SR-5333
Radar None
Original Reporter @ZevEisenberg
Type Bug
Status Reopened
Resolution
Environment

Xcode 8.3.2 (12175) and Xcode 9.0 (13158.29) on macOS 10.12.5 (16F73)

Additional Detail from JIRA
Votes 0
Component/s
Labels Bug
Assignee None
Priority Medium

md5: 2b8e71a548d799fd1663f55438fc259d

Issue Description:

enum MyEnum {
    case withAssociated(Int)
    case withoutAssociated
}

let foo: MyEnum = MyEnum.withoutAssociated

switch foo {
case .withAssociated(let int):
    print(int)
case .withoutAssociated(let whatAmI):
    print(whatAmI) // prints "()"
}

Works in Swift 3 and Swift 4.

I know this is the current (expected?) state of things, but it seems like a leaky abstraction that you can extract a value from an enum case that was explicitly declared not to have an associated value. I encountered this because I removed an associated value from a case that had previously had one, and all my code didn't break. (Admittedly, I wasn't yet doing anything with the associated value, because this was the early stages of some code; code the tries to do anything with the value besides printing it would likely encounter errors.)

I believe it would be a source-breaking change to remove the ability to extract a Void/() value from an enum case without an associated value, but it also seems like it might be better and less surprising than the current system.
@belkadan
Copy link
Contributor

This has actually been fixed in Swift 4! Coming soon to a beta near you.

@swift-ci
Copy link
Collaborator

Comment by Mauricio Cousillas (JIRA)

Reopening this one, i'm managing to reproduce it on Xcode 10.2 and swift 5.

https://forums.swift.org/t/compiler-bug-in-xcode-10-2-for-enums-with-associated-values/22280

@theblixguy
Copy link
Collaborator

Do you have an example? The example in this bug report throws an error as expected on Xcode 11 Beta 5. The example in the forum post seems unrelated?

@swift-ci
Copy link
Collaborator

Comment by Mauricio Cousillas (JIRA)

Sure! https://github.com/rootstrap/RSFormView/blob/master/RSFormView/Classes/ViewModels/FormViewModel.swift#L11 the FieldType enum is the one that is giving us trouble, if we remove the double(maxDecimalPlaces: Int) case, it works perfectly.

@theblixguy
Copy link
Collaborator

Sorry, but I don't understand what the issue is. How is that enum giving you a problem? Could you explain your problem in more detail? An isolated and reduced example would also help. Thanks!

@swift-ci
Copy link
Collaborator

Comment by Mauricio Cousillas (JIRA)

I'm not sure i can provide a smaller example, since I tried running the same enum isolated and it seems to work fine, but since the behaviour we are getting is so random, I can't tell 100% sure.

The issue that we have is for example:

1- I set that enum to .integer.

2- When I execute and debug the value, I see .email as the value.

On another project that we use that pod as a dependency we are getting al enums replaced as .password (that's why I say that it's a really inconsistent behavior).

EDIT: A bit more info

If you run the sample project on the pod and put a breakpoint in https://github.com/rootstrap/RSFormView/blob/master/RSFormView/Classes/Models/FormField.swift#L167

You will see that the 'Number of siblings' field will not be of type .integer but .email instead

@theblixguy
Copy link
Collaborator

Have you tried using the latest Xcode 11 beta? Does this issue only happens on debug builds or on release builds? (or both)?

@swift-ci
Copy link
Collaborator

Comment by Mauricio Cousillas (JIRA)

I didn't tested on xcode 11, because we don't have support for it yet on the pod.

We are having the issue both on production and development build, yes

@theblixguy
Copy link
Collaborator

I mean do you have this issue when you build with optimisations or without optimisations (or both)? (Talking about debug/release builds in Xcode, not dev/prod builds).

@swift-ci
Copy link
Collaborator

Comment by Mauricio Cousillas (JIRA)

Yes, we are getting it with and without optimisations (-O and -Onone)

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ZevEisenberg @belkadan @theblixguy @swift-ci