Shane F. Carr

> But if you have to implement a custom trait, I once again go back to comparing it with the motivation of reducing boilerplate: isn't the whole idea to _remove_...

_I don't think I agree with From/Into being a long-term goal we want to work toward._ \ I've tried, multiple times, to get my Rust trait frameworks to sit on...

If we wait for const traits to land, which I'm told by the lang team should be some time in the not-too-distant future, would you approve this with a trait-based...

For documentation, I still think I prefer a trait for the safe case (as well as the unsafe case) because 1. Structure between the two cases is more similar 2....

What did you think of this suggestion: > Should we consider an alternative such as having the proc macro paste the unsafe trait definition locally inside the file? The trait...

> I still have a preference for implementing the safe version of this and seeing how much we actually need the unsafe version. (I'm not aware of any call sites...

The impls I've mostly been looking at are things like PackedPattern, PatternItem, etc. Things with safety invariants and that might have a VarULE inside.

I think it is valuable and easy to review for the safety invariant to be "the input to this function MUST be the output of that function". It is easy...

What if databake produces an `unsafe impl` such that it must be inside of an `unsafe`? Does something like this work? ```rust type BakeParts = ...; impl Thing { #[doc(hidden)]...

My thought was that `databake::unsafe_impl_from_parts!` would generate an `unsafe impl` but with no commentary, such that hopefully maybe clippy would complain and force a manual safety comment. My only worry...