You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'll say I don't like the term "smart pointer" in Rust. It has a more specific meaning in C++ but porting that terminology over to Rust has been less than smooth. Like the Deref docs still imply that anything implementing the Deref trait is a "smart pointer" which is a bit of stretch on its own. But now #[derive(SmartPtr)] doesn't imply Deref and everything gets even more muddy.
I'd rather we use terms we can fully define without confusion. This feels similar to the "object safe" debate in that one aspect.
Reacted by Trevor Gross, Jubilee, Sergey Bugaev, Ludwig Stecher, matthieu-m, oxalica, LeoniePhiline, Aleksander Krauze and Rachel Knight
One option is to name it in relation to what it enables
I like this principle...
For example: #[derive(DynamicDispatch)] or #[derive(DynamicPtr)].
...but neither of these is "self explanatory" to me. What it enables specifically is the possibility of self: MyType<dyn Bar> appearing in traits and supporting dynamic dispatch, basically? Is that it? I am trying to page this back in.
It does two things. One, it allows coercions from MySmartPointer<ConcreteType> to MySmartPointer<dyn MyTrait>.
fnmain(){let ptr:MySmartPointer<i32> = MySmartPointer(Box::new(4));// This coercion would be an error without the derive.let ptr:MySmartPointer<dynMyTrait> = ptr;}
The other thing is that it makes self: MySmartPointer<Self> object-safe in traits.
traitMyTrait{// Arbitrary self types is enough for this.fnfunc(self:MySmartPointer<Self>);}// But this requires #[derive(SmartPointer)].fncall_func(value:MySmartPointer<dynMyTrait>){
value.func();}
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
That's true. I think I'm okay with it because we still allow the other kinds of coercion that make sense for a pointer (your code sample already compiles, in other words). I can't think of another kind of coercion we would want to allow behind a pointer type that isn't either already allowed or covered by this derive.
On a related note, I don't hate the idea of sticking with the already established CoerceUnsized, but I do think bothCoercePointee and UnsizePointee are better and clearer, and I still prefer the first (which are are FCP'ing).
Reacted by Alyssa Haroldsen, matthieu-m and Jarred Allen
CoercePointee, cf #129104 (comment) — though maybe whether the std::marker:: prefix is indeed required (from #129104 (comment)) could use one last clarification :3
I think it would still be required, I don't recall any discussion about the path and my understanding was that this would not be in the standard prelude to begin with.
Activity
ChrisDenton commentedon Aug 14, 2024
I'll say I don't like the term "smart pointer" in Rust. It has a more specific meaning in C++ but porting that terminology over to Rust has been less than smooth. Like the Deref docs still imply that anything implementing the
Dereftrait is a "smart pointer" which is a bit of stretch on its own. But now#[derive(SmartPtr)]doesn't implyDerefand everything gets even more muddy.I'd rather we use terms we can fully define without confusion. This feels similar to the "object safe" debate in that one aspect.
Darksonn commentedon Aug 15, 2024
One option is to name it in relation to what it enables. For example:
#[derive(DynamicDispatch)]or#[derive(DynamicPtr)].@rustbot label F-derive_smart_pointer
crlf0710 commentedon Aug 31, 2024
My personal two cents :)
Darksonn commentedon Sep 26, 2024
@crlf0710 Owned pointer is not good because it can be used with pointers that don't have ownership of the value.
I propose to use the name
#[derive(DynamicPtr)]. Any objections?nikomatsakis commentedon Oct 2, 2024
I like this principle...
...but neither of these is "self explanatory" to me. What it enables specifically is the possibility of
self: MyType<dyn Bar>appearing in traits and supporting dynamic dispatch, basically? Is that it? I am trying to page this back in.Darksonn commentedon Oct 2, 2024
It does two things. One, it allows coercions from
MySmartPointer<ConcreteType>toMySmartPointer<dyn MyTrait>.The other thing is that it makes
self: MySmartPointer<Self>object-safe in traits.nikomatsakis commentedon Oct 2, 2024
After discussion on Zulip, Alice and I would like to propose
derive(DynCapablePointer).nikomatsakis commentedon Oct 2, 2024
I'm going to go ahead and move to merge to move this up the lang priority
@rfcbot fcp merge
rfcbot commentedon Oct 2, 2024
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.
70 remaining items
tmandry commentedon Oct 11, 2024
That's true. I think I'm okay with it because we still allow the other kinds of coercion that make sense for a pointer (your code sample already compiles, in other words). I can't think of another kind of coercion we would want to allow behind a pointer type that isn't either already allowed or covered by this derive.
On a related note, I don't hate the idea of sticking with the already established
CoerceUnsized, but I do think bothCoercePointeeandUnsizePointeeare better and clearer, and I still prefer the first (which are are FCP'ing).rfcbot commentedon Oct 19, 2024
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
This will be merged soon.
Darksonn commentedon Oct 22, 2024
What name did we end up with?
lqd commentedon Oct 22, 2024
CoercePointee, cf #129104 (comment) — though maybe whether thestd::marker::prefix is indeed required (from #129104 (comment)) could use one last clarification :3tmandry commentedon Oct 23, 2024
I think it would still be required, I don't recall any discussion about the path and my understanding was that this would not be in the standard prelude to begin with.
Darksonn commentedon Oct 23, 2024
The intent is that this will not be in the prelude.
Rollup merge of rust-lang#131284 - dingxiangfei2009:rename-smart-ptr-…
Auto merge of rust-lang#131284 - dingxiangfei2009:rename-smart-ptr-to…
Darksonn commentedon Nov 15, 2024
Should this be closed now that #131284 is merged?