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-5819] Suggest as? AnyHashable when as? Equatable or as? Hashable is attempted #48389

Open
jckarter opened this issue Sep 1, 2017 · 7 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler itself diagnostics QoI Bug: Diagnostics Quality of Implementation good first issue Good for newcomers

Comments

@jckarter
Copy link
Contributor

jckarter commented Sep 1, 2017

Previous ID SR-5819
Radar None
Original Reporter @jckarter
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, DiagnosticsQoI, StarterBug
Assignee None
Priority Medium

md5: 5e4ffb6d40f711123adf86651f9a3a8f

Issue Description:

If you have two values of type Any or otherwise opaque type and you want to test whether they're equal, it's natural to try to write something like:

if let a = a as? Equatable, b = b as? Equatable {
  return a == b
}

Maybe someday that will work, but in the meantime dynamically casting to AnyHashable can get the desired effect. It'd be nice QoI to have a diagnostic telling people they can do this when they try similar things that don't.

@swift-ci
Copy link
Contributor

swift-ci commented Sep 4, 2017

Comment by Kevin Lundberg (JIRA)

I'm taking a stab at this, and I'm wondering if it's enough to just check any place where someone tries to do `blah as? Equatable`, or should this fix-it only apply inside conditional statements? Should it also apply for `as`/`as!`, and in a case like this? `let x: Equatable = "X"`

@belkadan
Copy link
Contributor

belkadan commented Sep 5, 2017

I'd rather not recommend casting to AnyHashable, which has subtleties of its own. Wouldn't a protocol shared by all your Equatable objects be a better idiom?

@jckarter
Copy link
Contributor Author

jckarter commented Sep 6, 2017

The subtleties should be transparent to most people, they only affect bridged ObjC types. If you have a protocol shared by all your Equatable objects, that protocol still can't refine Equatable without losing support for the existential type, and if it doesn't refine Equatable, you'll need to cast to AnyHashable to invoke ==.

@belkadan
Copy link
Contributor

belkadan commented Sep 6, 2017

The protocol doesn't have to look like Equatable to have the operation:

protocol InterestingType {
  func same(as other: InterestingType) // option 1
  func same<Other: InterestingType>(as other: Other) // option 2
}

But if all implementations of this are going to start with a type-check, maybe it doesn't matter.

@swift-ci
Copy link
Contributor

swift-ci commented Nov 1, 2018

Comment by Suyash Shekhar (JIRA)

Are there any updates or decision for this bug?

@jckarter
Copy link
Contributor Author

jckarter commented Nov 1, 2018

We haven't discussed this specifically recently. I still think this is a good idea, I don't know how @belkadan feels.

@belkadan
Copy link
Contributor

belkadan commented Nov 1, 2018

I still don't think it's a good idea, but I don't feel super strongly about it.

@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
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler itself diagnostics QoI Bug: Diagnostics Quality of Implementation good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants