reference
                                
                                 reference copied to clipboard
                                
                                    reference copied to clipboard
                            
                            
                            
                        Define field, element
We use "field" and "element" quite a lot but don't actually define what they are. We need to define them.
We could get rid of the use of "element" (in arrays and tuples) as a separate term and call them fields everywhere. AFAIK, there's no distinction between the two term except where we currently use them.
We may also want to introduce a term "active field" for whether or not the field can be accessed and padding bytes are padding bytes for the containing type. For example of why this would be useful, how do we describe padding of the field/element in A only exists when the value has the A discriminant?
#[repr(u8)]
enum Enum {
    A((u64, u32)),
    B(u128),
}
rustc error messages call elements fields as well:
error[E0609]: no field `1` on type `[(); 2]`
Nominating for discussion from the lang team with the following question:
How do we want to handle terminology for accessing the values in tuples, tuple structs, and arrays?
- Keep the status quo of the reference: Use fieldfor alphabetical names andelementfor numerical names and array values. If we do this, we may want to update the error messages inrustcthat say that e.g.1is a field of a tuple.
- Always call the nameable ones fields. So tuples and tuple structs would have fields 0,1, etc. just like the error messages say. Arrays would still have elements though, because you cannot use a field or tuple index expression to access them.
- Always call elements fields. Arrays included.
- Something else entirely?
As a side note, I wish we could just use tuple index expressions on arrays and then there'd be no difference between options 2 and 3.
We talked about this in the lang team triage meeting today. There were some thoughts that using "fields" for arrays would be surprising to people from most other languages.
There's some precedent in https://rust-lang.github.io/rfcs/1506-adt-kinds.html#tuple-structs
Tuple structs have 0 or more automatically-named fields
So we ended up at consensus that we might as well apply that to tuples as well, which I think is thus option 2.
(Not wearing my speaking-for-team hat for this part)
I wish we could just use tuple index expressions on arrays
Obligatory link to https://internals.rust-lang.org/t/nascent-idea-allow-0-1-etc-on-arrays/9250?u=scottmcm
I still think it'd be nice on arrays, though I understand that it working on arrays but not slices could be surprising to some. But maybe now that const generics exist and arrays are more usable, it'd be more helpful.