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-8777] CaseIterable synthesis should work in the presence of a manual AllCases typealias #51285

Open
lilyball mannequin opened this issue Sep 18, 2018 · 2 comments
Open

[SR-8777] CaseIterable synthesis should work in the presence of a manual AllCases typealias #51285

lilyball mannequin opened this issue Sep 18, 2018 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@lilyball
Copy link
Mannequin

lilyball mannequin commented Sep 18, 2018

Previous ID SR-8777
Radar None
Original Reporter @lilyball
Type Bug
Environment

Apple Swift version 4.2 (swiftlang-1000.11.37.1 clang-1000.11.45.1)
Target: x86_64-apple-darwin17.7.0

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

md5: 5a27fa3f9bb439cc95c51743b123a931

is duplicated by:

  • SR-9582 Change "can derive conformances" condition for CaseIterable

relates to:

  • SR-9582 Change "can derive conformances" condition for CaseIterable
  • SR-8776 Confusing error with broken CaseIterable conformance

Issue Description:

If I declare conformance to CaseIterable but also manually declare a typealias for AllCases, the compiler should still synthesize conformance as long as the AllCases type conforms to both Collection and ExpressibleByArrayLiteral. Right now attempting to do this produces a protocol 'CaseIterable' is broken error that AIUI is supposed to mean the compiler thinks the standard library's definition of CaseIterable is wrong.

The use-case here is writing something like

public enum Foo: CaseIterable {
    public typealias AllCases = Set<Foo>
    case one, two, three
}

I posted this on the forums and brentdax (JIRA User) suggested that this could be considered a bug fix.
@beccadax
Copy link
Contributor

To clarify: this might be small enough to be a bug fix—I don't know for sure. At the very least, though, there is definitely a diagnostic bug here.

@CodaFi
Copy link
Member

CodaFi commented Dec 18, 2018

This is exposing a more general problem with interactions with the derivation machinery and user-provided declarations

enum Foo: Int {
  typealias RawValue = UInt
  case one = 1, two = 2, three = 3
}

{{error: repl.swift:1:11: error: 'Foo' declares raw type 'Int', but does not conform to RawRepresentable and conformance could not be synthesized
enum Foo: Int {
^

error: repl.swift:1:6: error: protocol 'RawRepresentable' is broken; cannot derive conformance for type 'Foo'
enum Foo: Int {
^

error: repl.swift:1:6: error: protocol 'RawRepresentable' is broken; cannot derive conformance for type 'Foo'
enum Foo: Int {
^
}}

@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. compiler The Swift compiler in itself
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@beccadax @CodaFi