I stopped because I got logged out and was quite literally unable to get back in, even with email verification. Sounds like they did me a favor

Welp 😢

What for? Had a similar thing come up at work, and was able to use the fact that all callsites to trait methods appear in codegen to find a clever workaround.

But it sounds like this wouldn’t work for a more general library use case where the callers aren’t generated by codegen :/

I had a similar problem at work. I essentially needed trait specialization, but because the callers of the trait methods were all in codegen, I was able to make the trait generic over a marker type and then have the codegen “perform specialization” by turbofishing the marker type at each call site.

What are you trying to achieve?

Good point, I would need to think this through more.

On second thought, if there are no explicit view types, this would be strictly broader than existing Rust. So I think (?) it would be backwards compatible

Yup, it’s backwards incompatible ☹️ The pattern doesn’t need to be part of the type though, since we wouldn’t need view types. It would be similar to how partially moved out of structs work, where the compiler just tracks what’s going on instead of creating a new type.

Yes, but doing

fn push(Self { ref mut items, .. }: Self) { .. }

takes Self by value (and makes it an associated function). I’m suggesting that the semantics are changed to only take a mutable view of ‘items’. This would also need a way of attaching a lifetime to the borrow as well…

The use of “ref” and “ref mut” in matching already does a very similar thing today, what if we could extend this familiar syntax to function arguments?

fn add_successful(Self { ref mut successful, .. }: self) {
*successful += 1;
}

Congratulations Matt!! 🎉

This makes sense given their reasoning, will be curious to see how it turns out.