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-9956] classes defined inside functions can't be made to conform to Equatable? #52359

Closed
weissi opened this issue Feb 19, 2019 · 4 comments
Closed
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself conformances Feature → protocol: protocol conformances duplicate Resolution: Duplicates another issue nested types Feature: nested types operators Feature: operators type checker Area → compiler: Semantic analysis unexpected error Bug: Unexpected error

Comments

@weissi
Copy link
Member

weissi commented Feb 19, 2019

Previous ID SR-9956
Radar None
Original Reporter @weissi
Type Bug
Status Resolved
Resolution Duplicate
Environment

c

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

md5: c2436514a3ae706e9e8ec30597e978fc

duplicates:

  • SR-3092 Function-level nested types cannot conform to Equatable

Issue Description:

I have this Swift program

func foo() {
    final class Bar: Equatable {
        static func == (lhs: Bar, rhs: Bar) -> Bool {
            return lhs === rhs
        }
    }
}

which I think is totally fine but it claims that Bar doesn't conform to Equatable. Moving Bar outside the function foo however makes it compile.

Also: all works with {{struct}}s.

Error is

$ swift test.swift
test.swift:2:17: error: type 'Bar' does not conform to protocol 'Equatable'
    final class Bar: Equatable {
                ^
Swift.==:1:24: note: candidate would match if 'Bar' conformed to 'RawRepresentable'
@inlinable public func == <T>(lhs: T, rhs: T) -> Bool where T : RawRepresentable, T.RawValue : Equatable
                       ^
Swift.FloatingPoint:2:24: note: candidate would match if 'Bar' conformed to 'FloatingPoint'
    public static func == (lhs: Self, rhs: Self) -> Bool
                       ^
Swift.BinaryInteger:2:24: note: candidate would match if 'Bar' conformed to 'BinaryInteger'
    public static func == <Other>(lhs: Self, rhs: Other) -> Bool where Other : BinaryInteger
                       ^
Swift._Pointer:2:24: note: candidate would match if 'Bar' conformed to '_Pointer'
    public static func == (lhs: Self, rhs: Self) -> Bool
                       ^
Swift.Strideable:3:35: note: candidate would match if 'Bar' conformed to 'Strideable'
    @inlinable public static func == (x: Self, y: Self) -> Bool
                                  ^
Swift.StringProtocol:2:35: note: candidate would match if 'Bar' conformed to 'StringProtocol'
    @inlinable public static func == <RHS>(lhs: Self, rhs: RHS) -> Bool where RHS : StringProtocol
                                  ^
Swift.SIMD:4:24: note: candidate would match if 'Bar' conformed to 'SIMD'
    public static func == (lhs: Self, rhs: Self) -> Bool
                       ^
Swift.Equatable:2:17: note: protocol requires function '==' with type '(Bar, Bar) -> Bool'; do you want to add a stub?
    static func == (lhs: Self, rhs: Self) -> Bool
                    ^
@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@AnthonyLatsis AnthonyLatsis closed this as not planned Won't fix, can't repro, duplicate, stale Jun 3, 2022
@weissi weissi reopened this Jun 6, 2022
@weissi
Copy link
Member Author

weissi commented Jun 6, 2022

@AnthonyLatsis I noticed you closed this as 'not planned'. But this is a bug, no?

@AnthonyLatsis
Copy link
Collaborator

AnthonyLatsis commented Jun 6, 2022

Hi, Johannes! Apparently, all Jira duplicates, including this one, had already been closed 'as completed' when the issues were transferred. But when I was about to close some stray open duplicates of this issue I found the other day, I discovered that the 'duplicate' state is in the 'close as not planned' bucket (you can verify this by clicking the droplist next to the 'close' button), so I went ahead and reclosed the duplicates as 'not planned'. I realize this is misleading, and that I probably shouldn't have bothered reclosing them. With hindsight, I think we should mark duplicates using GitHub commands rather than closing them from now on.

@AnthonyLatsis
Copy link
Collaborator

AnthonyLatsis commented Jun 6, 2022

Duplicate of #45682

@weissi
Copy link
Member Author

weissi commented Jun 6, 2022

@AnthonyLatsis that makes sense, thank you for the explanation. Happy to dupe!

@weissi weissi closed this as completed Jun 6, 2022
@AnthonyLatsis AnthonyLatsis marked this as a duplicate of #45682 Jun 6, 2022
@AnthonyLatsis AnthonyLatsis added duplicate Resolution: Duplicates another issue type checker Area → compiler: Semantic analysis conformances Feature → protocol: protocol conformances operators Feature: operators nested types Feature: nested types unexpected error Bug: Unexpected error labels Feb 22, 2023
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 conformances Feature → protocol: protocol conformances duplicate Resolution: Duplicates another issue nested types Feature: nested types operators Feature: operators type checker Area → compiler: Semantic analysis unexpected error Bug: Unexpected error
Projects
None yet
Development

No branches or pull requests

2 participants