-
-
Couldn't load subscription status.
- Fork 17
Nospecialize on dynamic pairs #19
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #19 +/- ##
==========================================
+ Coverage 98.33% 98.36% +0.03%
==========================================
Files 7 7
Lines 421 429 +8
==========================================
+ Hits 414 422 +8
Misses 7 7
Continue to review full report at Codecov.
|
|
I'd have to run tests and benchmarks, but it looks like these are covered by |
I'm fine with whatever you're comfortable with. I don't want to give you unnecessary work but I also don't want to mess up any of your code. I think the most likely problem would be slow downs due to using |
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 don't really know anything about what @nospecialize does, how it is implemented, or what guarantees it'll have in the future, so I'm not really qualified to review.
|
All of this was implement in #55 |
There shouldn't be any changes to code inference. This does more of what #13 does but focuses on methods where one argument is static and one is dynamic, making it unnecessary to specialize on the static type.
@chriselrod, if this doesn't affect performance or constant propagation for your code libraries then it should be good to go.