Extending field projections to getters

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.

Isn't this "just" the proposed effects system?

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.

1 Like

I don't think so? I assume you're talking about this blogpost, which mentions api duplication due to mutability conflicts, but only in passing.

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.

1 Like

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.

2 Likes

Speak for yourself.

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.

that crate would become a lot more ergonomic if it could use field projections.