Repository navigation
Tracking issue for raw stabilization (raw::TraitObject) #27751
Description
The std::raw module exports some representation details for the purposes of transmuting and taking things apart. Stabilizing these means pinning down the representation details forever.
One possibility is to instead provide various conversions, rather than asking people to use transmute, when we're sure the conversions will always be possible. Methods like from_raw_parts are already doing this.
The TraitObject case in particular is unsettled due to the potential for upcasting in the future.
cc @carllerche
CURRENT STATUS AS OF 2016-08-18: Discussed in @rust-lang/lang meeting. The situation is this. We expect that this will be insufficient in the future, particularly if/when we support trait objects like Trait1+Trait2 (which would require 2 vtables). We could stabilize it, since it would remain correct for all existing objects, but it'd be a shame. In contrast, the various "custom DST" proposals would allow for a much more flexible way of extracting and creating this data (sort of like from_raw_parts), so we think we'd prefer to explore that route. (from #27751 (comment))
Activity
SimonSapin commentedon Aug 13, 2015
raw::Slicecan be replaced with[T]::len,[T]::as{,_mut}_ptr, andslice::from_raw_parts{,_mut}. Kill it.TraitObjectis used in Servo:std::error::Errordoes. It’s unfortunate thatstd::any::Anycan not be re-used. (I understood why at some point, but forgot.)obj.data as usizeas an identifier. (LayoutId,OpaqueFlow)&Flowtrait object to theBaseFlow(concrete struct) that is must be the first field of every implementors of theFlowtrait. Yes, relying on struct field order.Arc<Trait>beforeArcsupported DSTs. I’m trying to switch toArcnow.carllerche commentedon Aug 13, 2015
I have used
TraitObjecta number of times.One case, in the bytes crate, I use
TraitObjectto avoid an allocation, which can add up to a significant performance win in some cases (for example, when usingRope).The insight is that, pretty often, implementations of
ByteStrcan fit in a pointer size. So,Bytes, which is a wrapper around aByteStrtrait object does an optimization where the data component of the trait object gets "inlined".Another case I had was building a somewhat involved tree structure, there would be many pointers to the same trait object. The goal was to get an entire node of the tree to fit in a cache line and duplicating the vtable ptr prevented this. So, in this case, I saved the vtable pointer only once and "reconstructed" the trait object on demand.
Auto merge of #27866 - arielb1:really-fast-reject, r=nikomatsakis
kamalmarhubi commentedon Mar 5, 2016
I have a possible use case for stabilizing
Slice: I would like to use byte slices directly asstruct iovecforreadvandwritevin nix. There's an issue with more detail: nix-rust/nix#263Mostly I'm looking to exploit the (pointer, length) representation matching up with iovec, and thereby allowing a nice ergonomics win for calls using iovecs.
alexcrichton commentedon Mar 11, 2016
🔔 This issue is now entering its cycle-long final comment period 🔔
Specifically, the libs team is considering deprecating
raw::Sliceandraw::Repras these are replaced bystd::slicefunctions.@kamalmarhubi we specifically don't want to stabilize the layout of slices to be used in places like that, hence the deprecation!
SimonSapin commentedon Mar 11, 2016
Was
TraitObjectdiscussed?alexcrichton commentedon Mar 11, 2016
Yes, and we neither want to stabilize it nor deprecate it yet, this module will stick around for that reason.
aturon commentedon Mar 11, 2016
A bit more detail from the discussion at the meeting:
TraitObjectis, amongst the types that have ever appeared in this module, the most likely to change in the future. That's in part due to considerations about upcasting, multiple trait inheritance, and so on. It's unclear whether we will ever want to commit firmly to a representation here.That said, it'd be good to use this issue to track usecases for the raw representation, and see whether we can find other ways of accommodating them.
kamalmarhubi commentedon Mar 11, 2016
@alexcrichton
I figured as much. Maybe specialization and conditional compilation will let me be bad in the way I want to be there... :-)
Thanks for the ping!
33 remaining items
durka commentedon Oct 13, 2017
SimonSapin commentedon Oct 13, 2017
Even if the repr changes it has to include at least a data pointer, doesn’t it?
durka commentedon Oct 13, 2017
The reference says it is a "pointer-to-pointer cast" but doesn't say what that means. Sounds OK though?
eddyb commentedon Oct 13, 2017
@durka The casts are properly defined and there's even fat-to-fat casts which check the metadata and whatnot - they might be described in an RFC, or not at all, but that's orthogonal.
SimonSapin commentedon Oct 13, 2017
https://doc.rust-lang.org/nightly/nomicon/casts.html says:
and
Maybe it’s time to fix that TODO and define this more precisely?
SimonSapin commentedon Oct 28, 2018
rust-lang/rfcs#2580 proposes deprecating this.
SimonSapin commentedon Apr 15, 2021
Deprecation PR: #84207
SimonSapin commentedon Apr 15, 2021
As an unstable feature, this can be removed a couple release cycles after the deprecation warning has been in place.
crlf0710 commentedon Jul 3, 2021
Opened a removal pr at #86833.
Auto merge of rust-lang#86833 - crlf0710:remove-std-raw-mod, r=SimonS…