reference icon indicating copy to clipboard operation
reference copied to clipboard

Define field, element

Open Havvy opened this issue 4 years ago • 3 comments

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),
}

Havvy avatar Jan 17 '21 07:01 Havvy

rustc error messages call elements fields as well:

error[E0609]: no field `1` on type `[(); 2]`

Havvy avatar Mar 16 '21 06:03 Havvy

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?

  1. Keep the status quo of the reference: Use field for alphabetical names and element for numerical names and array values. If we do this, we may want to update the error messages in rustc that say that e.g. 1 is a field of a tuple.
  2. 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.
  3. Always call elements fields. Arrays included.
  4. 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.

Havvy avatar Mar 16 '21 07:03 Havvy

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.

scottmcm avatar Mar 16 '21 17:03 scottmcm