August 23, 2023

On Wednesday, 23 August 2023 at 16:28:27 UTC, Andrey Zherikov wrote:

>

On Wednesday, 23 August 2023 at 15:32:02 UTC, Paul Backus wrote:

>

For this use case, you should use .tupleof instead of __traits(allMembers), which is guaranteed by the spec to give the fields in declaration order.

This link says "The order of the fields in the tuple matches the order in which the fields are declared" for the classes. I don't see such statement for structs here.

The spec isn't totally clear, but I believe the intent is to say that it works the same way for structs unless otherwise stated. Certainly, in practice, the fields are always in declaration order.

August 23, 2023
On 8/23/23 18:28, Andrey Zherikov wrote:
> On Wednesday, 23 August 2023 at 15:32:02 UTC, Paul Backus wrote:
>> For this use case, you should use `.tupleof` instead of `__traits(allMembers)`, which [is guaranteed by the spec to give the fields in declaration order][1].
>>
>> [1]: https://dlang.org/spec/class.html#class_properties
> 
> This link says "The order of the fields in the tuple matches the order in which the fields are declared" for the classes. I don't see such statement for structs [here](https://dlang.org/spec/struct.html#struct_instance_properties).

Well, it refers to the class version and I think it is clear that it must be ordered. Anyway, if you don't trust this for some reason, you can always just sort by "offsetof". (Provided you don't want to use empty static arrays.)
August 24, 2023

On Wednesday, 23 August 2023 at 13:53:30 UTC, Andrey Zherikov wrote:

>

On Wednesday, 23 August 2023 at 12:39:09 UTC, Adam D Ruppe wrote:

>

On Wednesday, 23 August 2023 at 12:32:58 UTC, Andrey Zherikov wrote:

>

Is it possible to define an order at least for some cases (I'm looking for structs actually)?

What do you do with the order of declaration?

I'm developing a library to parse command line arguments. One type of arguments is positional argument which means that they have a position in command line.
As of now (because the order of allMembers is not defined), these arguments are attributed the following way by explicitly providing the order:

struct Params
{
    @PositionalArgument(0)
    string firstName;

    @PositionalArgument(1)
    string middleName;

    @PositionalArgument(2)
    string lastName;
}

If allMembers guarantees the order to be the same as the members are declared then the code above can be simplified to this:

struct Params
{
    @PositionalArgument
    string firstName, middleName, lastName;
}

Just sort allMembers by .offsetof? You might need a small amount of compile time gymnastics but it’s doable.

August 24, 2023

On Thursday, 24 August 2023 at 00:11:07 UTC, John Colvin wrote:

>

Just sort allMembers by .offsetof? You might need a small amount of compile time gymnastics but it’s doable.

Adds quite a bit of potential complication - what if two things have the same offset of? What if they don't have one? Doing this without care can bloat compile times too...

but yeah, it was my first thought too tbh, with the appropriate filters you can make that work.

August 23, 2023
On 8/23/2023 2:17 PM, Timon Gehr wrote:
> Well, it refers to the class version and I think it is clear that it must be ordered.

Yes. It is written the way it is because I was writing a lot of text in the spec and didn't want to repeat things.

Another problem with repetition is the texts will inevitably diverge, and then the poor reader wonders why they are different.

1 2
Next ›   Last »