a lot of people want to extend field projections to apply to more types of things, such as Pin, but what about extending the ways of projecting, as a form of generic mutability?
i'm imagining some sort of &~mut self syntax, mirroring the ~const syntax.
no idea if this makes sense, but i had these thoughts and i wanted to write them down somewhere.
I can not stop myself from mentioning my crate generic-mutability, which seeks to unify & and &mut into a single generic type and allowing libraries implement generic mutability getter methods.
Of course, without syntax support, projecting to fields only works via macros, even with my crate.
Thinking about it, the semantics seem fairly simple. A &~mut reference inherits all the limitations of both shared and exclusive references, so it is typechecked as a &mut reference, does not implement Copy, but cannot be assigned to.
Any type of reference can be reborrowed into a &~mut reference, an a &~mut reference.
Similar to lifetimes, no actual monomorphization is needed, since the mutability will be erased past a certain point in codegen.
If implemented correctly, switching a function from &T to &~mut T could be made backwards compatible, allowing us to deprecate a bunch of _mut functions.
The main difficulty is if we want to allow multiple sets of ~mut in a function signature to resolve to different mutabilities. This is of dubious use unless you are returning a tuple of pointers, but perhaps it could be based on lifetimes? Additionally, how would they work in structs?
This could also be applied to raw pointers in much the same way.
The connection to effects comes from the fact that people are rightly sceptical of the ad-hoc nature of ~const, and would rather reify effect-like attributes (asyncness, mutability, runtimeness (as in non-constness), etc) as first class entities in the type system so generic items can be parametric over them like they can with the current kinds of generic parameters.
Not everyone who is skeptical of ~const would rather reify effect-like attributes.
Both add unnecessary accidental complexity to an already hugely complex language and are a bad direction for Rust. The further Rust proceeds along this erroneous path, the more users it will lose in favor of simpler approaches such as Zig.