Skip to content
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

Consider renaming (Re)EarlyBound to ReParam and (Re)LateBound to Bound. #70805

Open
eddyb opened this issue Apr 5, 2020 · 1 comment
Open
Labels
A-lifetimes Area: lifetime related A-typesystem Area: The type system C-cleanup Category: PRs that clean code up or issues documenting cleanup. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@eddyb
Copy link
Member

eddyb commented Apr 5, 2020

This convention would be slightly less confusing due to aligning better with Ty and ty::Const.

On the other hand, the early-bound vs late-bound terminology is so baked-in that this might be hard.

cc @rust-lang/wg-traits @matthewjasper

@eddyb eddyb added C-cleanup Category: PRs that clean code up or issues documenting cleanup. A-typesystem Area: The type system A-lifetimes Area: lifetime related T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 5, 2020
@nikomatsakis
Copy link
Contributor

Yes, I agree this is a terminology question to reconcile -- but more generally I think we want to ask ourselves is whether to revisit how we handle parameters altogether. In Chalk, there is no early/late bound distinction: there are only "bound things", and we use them for everything. We also always substitute bound things with placeholders or other free things when using them.

This is in contrast to the rustc approach of using Param and knowing from context whether it's to be treated as something bound or as a placeholder.

I think we should settle on one. I think the chalk approach is cleaner and would probably help prevent that weird behavior we get from time to time when someone forgets to apply a substitution (if we play our cards right, we could probably prevent that behavior statically by having two distinct Interner generic types, one for unsubstituted types and one for substituted types, although actually we can do that in either case I suppose).

On the other hand, the rustc approach means less overall substitution and types created, and this may have some memory/performance benefits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: lifetime related A-typesystem Area: The type system C-cleanup Category: PRs that clean code up or issues documenting cleanup. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants