Need for -> operator for Unsafe Code Guidelines

61

There are subtly different requirements at work here. The code that spawned the issue was due to unergonomic access to pointer math for fields. Your code actually needs to read from the field inner to get the second pointer. And that should be a strong distinction, I think. Another reason why I dislike the current code patterns because it very much conflates the two issues.

&(*ptr).inner as *const _ // 'Just' pointer math

&(*(*ptr).inner).field) as *const _ // Reads from inner

With respect to code, the problem I see new syntax being most useful in solving would be

struct FooMe { inner: BarMe }
struct BarMe { field: u8 }

unsafe fn init_field(ptr: *const FooMe) -> *const u8 {
    ptr~inner~field // Bikeshedding but that's free as binary operator?
}

// Also helps and makes explicit your version:
unsafe fn init_through_field(ptr: *const Foo) -> *const u8 {
    (*ptr~inner)~field
}

And in the context of MaybeUnint I'm dreaming of a safe solution to grabbing a pointer to initialize fields.

fn init_field(uninit: &mut MaybeUninit<Foo>) {
    uninit.as_init()~inner~field.write(0);
}
1 Like