Specialize builder functions where unambiguous #549
Merged
Conversation
This file contains hidden or 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
Remove generic parameters which are actually used only with a single concrete type, substituting that type instead. E.g. a function `fn foo<E: Make<Box<Expr>>, T: Make<Box<Type>>(e: E, t: T)` is turned into a function `fn foo(e: Box<Expr>, t: Box<Type>)`. This doesn't restrict the usages of the function in any way, since the only type which is `Make<Box<Expr>>` is `Box<Expr>` itself. These generic parameters are strictly redundant. They produce generic bloat, harm compile times, complicate the API, and prevent type inference for function arguments (i.e. if `foo(f1(), f2())` and either `f1` or `f2` is generic in its return type, then type inference will fail). Using the concrete types is strictly better, and opens the possibility of more ergonomic API with better type inference.
kkysen
force-pushed
the
specialize-builder
branch
from
d7ebcd4 to
06f6c41
Compare
|
Rebased against |
kkysen
approved these changes
Jul 19, 2022
There was a problem hiding this comment.
As you noted, @fw-immunant already reviewed and approved these changes in #485 (comment), and I agree they are very helpful in reducing unnecessary generics and improving inference.
This does cause some clippy::boxed_local warnings, but I'll fix them separately (#550), as it's not a tiny fix.
kkysen
added a commit
that referenced
this pull request
Jul 19, 2022
… `Vec::new()`/`vec![]`, which were surfaced by #549 but missed in that PR.
kkysen
added a commit
that referenced
this pull request
Jul 19, 2022
…ing in #549, as well as the cascading de-`Box`ing.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Remove generic parameters which are actually used only with a single concrete type, substituting that
type instead.
E.g. a function
fn foo<E: Make<Box<Expr>>, T: Make<Box<Type>>(e: E, t: T)is turned into a functionfn foo(e: Box<Expr>, t: Box<Type>).This doesn't restrict the usages of the function in any way, since the only type which is
Make<Box<Expr>>is
Box<Expr>itself. These generic parameters are strictly redundant. They produce generic bloat, harmcompile times, complicate the API, and prevent type inference for function arguments (i.e. if
foo(f1(), f2())and either
f1orf2is generic in its return type, then type inference will fail).Using the concrete types is strictly better, and opens the possibility of more ergonomic API with better type
inference.
Also remove the explicit type casts which were required only due to the overly generic API, and can now be safely elided.
This PR was split from #485. As far as I can tell from the discussion in #485, this change is uncontroversial.
This PR builds on the branch of #548 and should be merged after it to avoid merge conflicts.