-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Remove impl of Allocator for &A #123213
base: master
Are you sure you want to change the base?
Remove impl of Allocator for &A #123213
Conversation
A T-opsem convo on Zulip pointed out that this is hard to optimize-out: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/abi.20compat.20of.20.26mut.20T.20and.20*mut.20T.20where.20T.20is.20a.20ZST/near/429718899 This impl merely existing makes the opt story around `Allocated<T, A>`, e.g. `Vec<T, A>`, `Box<T, A>`, etc. much worse. Now, there may be cases where we would want this pattern to be used but we can let implementors decide: We do not need to force everyone to be implicitly opted-into it.
rustbot has assigned @Mark-Simulacrum. Use |
The job Click to see the possible cause of the failure (guessed by this bot)
|
didn't realize we actually depended on this lmao. |
The PR description doesn't seem accurate to me. This impl existing or not doesn't by itself make things harder to optimize - the problem is rather that allocators are not bounded by : Copy and lack a way to get a ZST handle if that's possible for that type. This impl just makes it easier to accidentally pass an Allocator that's a ZST by reference instead of by copy which does make things needlessly slower. I think the right solution is something like a |
yeah I probably should've said something like "makes it easier to deoptimize your own code by mistake". |
Cc #98232 |
@workingjubilee any updates on this? thanks |
A T-opsem convo on Zulip pointed out that this is hard to optimize-out:
https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/abi.20compat.20of.20.26mut.20T.20and.20*mut.20T.20where.20T.20is.20a.20ZST/near/429718899
This impl merely existing makes the opt story around
Allocated<T, A>
, e.g.Vec<T, A>
,Box<T, A>
, etc. much worse. Now, there may be cases where we would want this pattern to be used but we can let implementors decide: We do not need to force everyone to be implicitly opted-into it.