I like this version a lot more. I know that when requires lands we probably won’t be able to do
fn foo[T](read t: T) requires T is Movable and T.__moveinit__is_trivial:
...
On day one, but it gives us a good path forwards for trivial to be better integrated into the stdlib.
I think this might be a dangerous thing to do, considering that what “register passable” means is a bit up to the programmer. Does it mean the scalar GP registers? Or the 64 byte AVX512 registers? Or the 1 KiB AMX registers?
Having some more control in this area would be welcome, since I have plenty of structs that fit into an AVX512 register but on systems without registers of that size it causes some fairly odd performance hits. Having this compiler synthesized thing become target dependent could be messy, especially since it gets used for as a trait bound.
Yep i think your thinking is correct,
if you need fine control over the registers,
an auto-optimization would not be good.
It is just an easy opt-in decorator after all!
(not that huge of a learn)
I’m really happy with this new design for triviality. It appears to be a fleshed-out version of the design that I proposed in my last post on this thread. 
Mojo is really shaping up to be a fantastic language. I’m stoked.
While writing some new optimizations for List and Span based on the new triviality traits I realized we might even extend this further. If we know the type’s logical comparisons are also trivial, once we have reflection and we can tell what bitwidth the fields are, then we could use vectorized comparisons for such types automatically 
Trivial Eq should be pretty easy to do. Less than or greater than might be harder if you have signed types or floats mixed in.