Open eddyb opened 8 years ago
Nominating for discussion next week. In this week's compiler team meeting, @arielb1 raised concerns about leaving (ab)uses of unsound specialization in the compiler, which I am sympathetic to. It'd be good to figure out how we can prioritize moving away from that.
I believe we can reduce our deriving needs to a single "ShapeReflect
" trait with 4 operations:
Self -> (fields...)
&Self -> (&fields...)
&mut Self -> (&mut fields...)
(fields...) -> Self
Even without VG we can build implementations of all sorts of operations we need (such as Relate
which does (&T, &T) -> Result<T, E>
) out of this one trait + specialization.
EDITs:
HList
pattern.First | Rest
, using an enum with two variants
Currently, we're limited to the general-purpose
Eq
,Ord
,Hash
,Encodable
andDecodable
traits, even though the compiler often has more unconventional desires, involving contexts and custom behaviors.There are several special-purpose traits already in the compiler, such as AST/HIR
Folder
/Visitor
and the two-in-oneTypeFoldable
(which also does visiting).Also, #36551 adds a specialization mechanism in the bundled
rustc_serialize
to work around the fact thatEncodable
andDecodable
have their methods be generic over the encoder/decoder instead of the trait, but this abuses the yet-unclosed lifetime soundness hole in specialization (#31844):That
impl
requires that the'tcx
of the decodedTy
match the'tcx
of the decoder, but this cannot be enforced through specialization as the lifetime relationships do not exist before monomorphization.A better solution would involve custom traits that can dispatch over the decoder w/o specialization, i.e.:
To make all of this ergonomic, auto-deriving is necessary, and I believe macros 1.1 (perhaps helped by a permanent switch to rustbuild) can make it happen.
Last but not least, it may be possible to generalize encoding/decoding and visiting/folding/relating into a single (or a pair of) abstraction(s), but I'd have to leave that to someone who understands tree folding, transducers, and perhaps Haskell lenses, although there's no guarantee they map nicely to Rust.
cc @rust-lang/compiler