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-4273] Hashable & default function arg #46856
Comments
I swear we've seen this before but I can't find it. Regardless, this wouldn't be valid because generic parameters can be controlled by context:
We'd have to have the notion of a default argument value that only kicks in under certain conditions, which gets complicated. You might as well just use overloads for that. |
Comment by Andrew Pleshkov (JIRA) Oh, I see, thanks. Actually using such default argument was an attempt to fix this: func find<T, Q: Hashable>(key: T, qualifier: Q? = nil) {
// ...
}
find(key: "foo") // Generic parameter 'Q' could not be inferred So I use an overload: func find(key: String) {
let q: AnyHashable? = nil
find(key: key, qualifier: q)
} And everything is fine. |
Not today, sorry. People have talked about adding "default types" to generic parameters but that would be a whole new language feature. |
Comment by Andrew Pleshkov (JIRA) But what totally solves my issue is using So I can rewrite func find(key: String, qualifier: AnyHashable? = nil) {
// ...
}
find(key: "foo") // compiles
find(key: "foo", qualifier: "kekeke") // compiles
find(key: "foo", qualifier: 123) // compiles But it looks like a side-effect. Will such auto-boxing be broken in the future? |
That means something different: now you've lost the type of the qualifier even when it's not nil. If that's not important to you this is a perfectly acceptable solution. |
Comment by Andrew Pleshkov (JIRA) In my case I just want the |
Comment by Andrew Pleshkov (JIRA) Thus can using of auto-boxing of one concrete |
I thought it documented as part of the proposal that introduced AnyHashable, but maybe not. @jckarter? |
It should also be in the language docs if it isn't already. Maybe we missed it—@jackhl might know where to look. |
https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md was the evolution proposal. |
It's mentioned in Using Swift with Cocoa and Objective-C -> Interacting with Objective-C APIs -> Hashing:
However it is not discussed at all in The Swift Programming Language book or the AnyHashable API reference. Since this behavior seems useful/important beyond Objective-C interop, I'll talk to the docs team about possibly adding more information in a more prominent location. |
Comment by Andrew Pleshkov (JIRA) Awesome, thanks a lot! |
Environment
$ swift --version
Apple Swift version 3.0.2 (swiftlang-800.0.63 clang-800.0.42.1)
Target: x86_64-apple-macosx10.9
Additional Detail from JIRA
md5: ba342c2e335167507d0b29222fc96dc1
Issue Description:
I use
Hashable
as a type constraint in my function, but it produces an error:Same with string:
Same with
AnyHashable
:Thus in case of e.g.
""
I expect:The text was updated successfully, but these errors were encountered: