This is a follow-up to #1456.

The discussion hit a point where we had 2 proposals for how pointer operations would work, and we agreed to proceed with an intersection. This means, . and [] are not defined on pointers. This issue is about providing this ability to get a pointer from an element of a composite type, given a pointer to the composite. Suggested syntax:

struct Bar {
  unused: vec4<f32>;
};
struct Foo {
  x: array<i32, 5>;
  y: Bar;
};

fn foo(ps: pointer<Bar, Private>) {
  const px: pointer<array<i32, 5>, Private> = ps.x;
  const py: pointer<i32, 5, Private> = px[3]; // same as `ps.x[3]`.
  *py = 4; // store
  *ps.x[0] = 1; // also store. The "." has a precedence over "*"
  const py: pointer<vec4<f32>> = ps.y.unused;
  *py = vec4<f32>(0.0);
}

Currently, if I understand correctly, taking a pointer to a member would look like this: &(*ps).x. The new semantic of "." and "[]" in this proposal would match OpAccessChain SPIR-V instruction, which operates on pointers and supports a chain of jumps.
@dneto0 please feel free to edit the issue if I expressed it incorrectly or unclear