Thread overview
std.traits.Fields(T), FieldNameTuple(T) - order guaranteed?
Jul 27, 2016
Liam McSherry
Jul 27, 2016
Meta
Jul 27, 2016
Jonathan M Davis
July 27, 2016
Since it isn't mentioned in the documentation, do `std.traits.Fields(T)` and `std.traits.FieldNameTuple(T)` return the fields and field names in a deterministic order?

Further, will they return the fields/field names in the same order? That is, will `fields[0]` be the type of `field_names[0]`?
July 27, 2016
On Wednesday, 27 July 2016 at 13:09:07 UTC, Liam McSherry wrote:
> Since it isn't mentioned in the documentation, do `std.traits.Fields(T)` and `std.traits.FieldNameTuple(T)` return the fields and field names in a deterministic order?
>
> Further, will they return the fields/field names in the same order? That is, will `fields[0]` be the type of `field_names[0]`?

I think you should be safe here as Fields is basically a wrapper around T.tupleof, which should always return fields in the same order. It's not guaranteed anywhere, but it's highly unlikely to change.

Since FieldNameTuple is also implemented using T.tupleof, you *can* expect Fields!T[0] to be the type of FieldNameTuple!T[0]. Again, however, this is an implementation detail that is unlikely to change but is not guaranteed.
July 27, 2016
On Wednesday, July 27, 2016 13:09:07 Liam McSherry via Digitalmars-d wrote:
> Since it isn't mentioned in the documentation, do
> `std.traits.Fields(T)` and `std.traits.FieldNameTuple(T)` return
> the fields and field names in a deterministic order?
>
> Further, will they return the fields/field names in the same order? That is, will `fields[0]` be the type of `field_names[0]`?

It's not guaranteed, but given their implementations and what they do, it will almost certainly always be true. But given that it's not guaranteed, I'm not sure that it would be a great idea to rely on it.

However, there's really no point in relying on it. Just use Fields and use stringof on a field when you want its name. That's all that FieldNameTuple is really doing internally anyway.

- Jonathan M Davis