-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
fewer convert
methods for Missing
and Nothing
(take 2)
#31602
Conversation
Do we need to add something to be able to infer |
It apparently seems to be working ok already |
Should we go with this, or at least bring up in triage it? |
Doesn't seem urgent. I would also like to understand how we're able to infer |
Now that we've branched, can we land this on master and see how well it works out? I didn't intend for inference to handle |
1fb2e92
to
09be236
Compare
addresses and issue where we might be ambigous with other badly designed methods such as the ambiguous Nothing/Missing rules (cf #31602)
addresses an issue where we might be find an ambiguity with badly designed methods, such as the ambiguous Nothing/Missing rules (cf #31602)
addresses an issue where we might be find an ambiguity with badly designed methods, such as the ambiguous Nothing/Missing rules (cf #31602)
addresses an issue where we might be find an ambiguity with badly designed methods, such as the ambiguous Nothing/Missing rules (cf #31602)
And use `typesubtract` instead of subtyping to improve usability by handling undef sparams. Co-Authored-By: Jameson Nash <[email protected]>
09be236
to
3888a6c
Compare
I'd like to land this before the feature freeze (although I suppose it should be non-breaking anyways), and give it some time to see how it works out in practice since it seems to need many fewer methods and just handles them with more ease. |
@@ -163,6 +163,7 @@ true | |||
""" | |||
function convert end | |||
|
|||
convert(::Type{Union{}}, x) = throw(MethodError(convert, (Union{}, x))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this here to give a predictable ambiguity error instead of an ambiguity error involving two random methods? I suppose that's fine, just wondering if there is any other reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you say, "predictability" :)
addresses an issue where we might be find an ambiguity with badly designed methods, such as the ambiguous Nothing/Missing rules (cf #31602)
This should make it impossible to accidentally define or call this method on foreign types. Refs: JuliaLang#31602 Fixes: JuliaLang#45837 Closes: JuliaLang#45051
This should make it impossible to accidentally define or call this method on foreign types. Refs: JuliaLang#31602 Fixes: JuliaLang#45837 Closes: JuliaLang#45051
And use
typesubtract
instead of subtyping to improve usability by handling undef sparams.closes #30205