4 ms·

Interesting write-up. Unsafe pointers are definitely due for an overhaul. Suggestion on syntax: just use ‘->’ It has the familiarity from C already. Most rust

Interesting write-up. Unsafe pointers are definitely due for an overhaul. Suggestion on syntax: just use ‘->’ It has the familiarity from C already. Most rust unsafe programmers are long time C/C++ folks. You can define them to only work on raw pointers (like C) and always produce pointers (unlike C). And using it means no auto-deref magic E.g. ptr->field3->[0]->write(7);

nickitolas 5y ago
I think the familiarity might be a double edged sword, since AIUI the proposed operator has different semantics. "ptr~field~field2" is not "ptr->field->field2", it's more like "&(&ptr->field)->field2". Therefore I feel like the familiarity might just confuse people or give them a false sense of security.
- xorvoid 5y ago
  Meh. It’s harmless. You get a helpful compiler error the first time and you very quickly learn. I’ve been a C programmer for >20 years and this slight difference wouldn’t bother me. Explaining it is simple: ‘.’ uses a reference and produces a reference ‘->’ uses a pointer and produces a pointer
  - heinrich5991 5y ago
    `.` only produces a reference if you explicitly reference the result. `a.b` is of type `B`, only `&a.b` is `&B` and `&mut a.b` is `&mut B`. This is unlike your proposal of `->` where `a->b` would be `*const B`.
  - estebank 5y ago
    The problem is not ibvalid.code being rejected with an error, but rather code that is accepted but does something unexpected. Lints can help with that, but that has many limits.
Gankra 5y ago
~ is not -> ptr->field in C is (*ptr).field, at which point you are in whatever C's equivalent of a "place (lvalue) expression" is. This creates a weird discontinuity where you -> for the first step and then use `.` for subsequent steps and then do the standard "just kidding, it was a pointer offset all along" thing of slapping `&` in front of it. My proposed ~ always keeps you indirected so you just use ~ all the way until you actually want to load a value from memory (which in C would implicitly happen whenever you have a nested ->).

nickitolas 5y ago

I think the familiarity might be a double edged sword, since AIUI the proposed operator has different semantics. "ptr~field~field2" is not "ptr->field->field2", it's more like "&(&ptr->field)->field2". Therefore I feel like the familiarity might just confuse people or give them a false sense of security.

xorvoid 5y ago
Meh. It’s harmless. You get a helpful compiler error the first time and you very quickly learn. I’ve been a C programmer for >20 years and this slight difference wouldn’t bother me. Explaining it is simple: ‘.’ uses a reference and produces a reference ‘->’ uses a pointer and produces a pointer
- heinrich5991 5y ago
  `.` only produces a reference if you explicitly reference the result. `a.b` is of type `B`, only `&a.b` is `&B` and `&mut a.b` is `&mut B`. This is unlike your proposal of `->` where `a->b` would be `*const B`.
- estebank 5y ago
  The problem is not ibvalid.code being rejected with an error, but rather code that is accepted but does something unexpected. Lints can help with that, but that has many limits.

Gankra 5y ago

~ is not -> ptr->field in C is (*ptr).field, at which point you are in whatever C's equivalent of a "place (lvalue) expression" is. This creates a weird discontinuity where you -> for the first step and then use `.` for subsequent steps and then do the standard "just kidding, it was a pointer offset all along" thing of slapping `&` in front of it. My proposed ~ always keeps you indirected so you just use ~ all the way until you actually want to load a value from memory (which in C would implicitly happen whenever you have a nested ->).