-
-
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
RFC: lower x^literal as x^Val{literal} for integer literals #20530
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
b453ba6
lower x^literal as x^Val{literal} for small integer literals (closes …
stevengj ce13a79
simplify smallnum check since all Ints get inlined as fixnums into Sc…
stevengj 7eeefee
do x^Val{p} transformation for all literal p, not just small ones
stevengj 5411736
fix comment
stevengj a7f1f45
docs for x^Val{p}
stevengj f23f250
documentation tweak
stevengj 3a0d354
added test for x^literal
stevengj d1dab59
note experimental feature [ci skip]
stevengj File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
How about we rewrite this as
^(x, p) = internal_pow(x, p)
and then dispatch onVal
ininternal_pow
? I ask because this is going to be a magnet for ambiguities since packages are likely to specialize on the first argument. E.g., PainterQubits/Unitful.jl#54There 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.
Unitful will maybe want to write its own
^(x, Val{p})
methods that are type-stable anyway, however, so in this case the ambiguity warning is helpful.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.
But I guess it doesn't hurt to do this, and it may be helpful in other cases?
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.
I dunno, the more I think about it the more I think that the ambiguity warning is actually helpful here. Particularly if we start inlining
x^Val{p}
, anyone specializing purely on the first argument (and not restricting top::Number
, as most types would) will want to explicitly decide what to do for theVal{p}
case.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.
these won't be warnings any more, they'll be errors the first time someone happens to call the ambiguous signature, unless you're going out of your way to check for ambiguities
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.
Unitful wasn't even getting through precompilation, because some of these run at build time and the ambiguity error kicks in. These are fixable errors, as witnessed by that PR, but I don't personally see much downside to engineering the dispatch chain to avoid breakage.
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.
The downside is that packages that really should be thinking about doing something different for
Val{p}
will get no warning of the change.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.
But I don't feel strongly about this; I've updated #20648 to use
internal_pow
as you suggest.