Rename reads_and_writes field of Access to reads

[alice-i-cecile]

Objective

• this field is confusingly named, as the ability to write to a field necessarily implies the ability to read
  • for an example of this friction, see Add &mut World as a system param and make .exclusive_system() optional #4166 (comment)
• the logic here is reads | writes == reads, not reads & writes

Solution

• rename field
• improve doc comments

Additional Context

In an ideal world, this would look something like

enum AccessLevel {
   Nothing,
   Reads,
   Writes,
}

Unfortunately, this is perf-critical code, so we're using a bitset to allow for quick comparisons.

If and when we want to extend Access to support more exotic access types (like presence for the existence of a component type or forge for the ability to add components of that type), the name makes even less sense.

[bjorn3]

this field is confusingly named, as the ability to write to a field necessarily implies the ability to read

Not necessarily. You could make a SystemParam which can only write and not read.

[alice-i-cecile]

You could make a SystemParam which can only write and not read.

This isn't really representable under Rust's aliased mutability rules, and it would not be any easier to schedule. I would actually like to add a debug-assert to verify the subset invariant, but I decided to keep it out of this particular PR.

[cart]

The idea here was to be explicit that this isn't "exclusively reads" (which would be an easy assumption to make for something called reads when writes exists).

reads_and_writes could definitely be misinterpreted as "exclusively reads and writes", but that feels less risky here in the global context of the type. Happy to consider renames (especially ones that are completely unambiguous), but I personally don't think that as written this is a positive step towards more safety.

[alice-i-cecile]

Going to close this out. There's a clearer model to be used here (the 4 access level model described in the old Forge component RFC), and I think we should just migrate to that.

See also #4624.