On 6/26/23 21:25, Chris Katko wrote:

> How do I get just the field name?

I know .tupleof, which you can typeof() as well:

class myObject{
    int field1, field2, field3;

    static foreach(field; typeof(this).tupleof)
    {
        pragma(msg, field.stringof);
    }

    static foreach(MemberType; typeof(typeof(this).tupleof)) {
        pragma(msg, MemberType);
    }
}

The output:

field1
field2
field3
int
int
int

I had to consult what I wrote years ago:

  http://ddili.org/ders/d.en/tuples.html#ix_tuples..tupleof

Ali

On Monday, June 26, 2023 10:25:13 PM MDT Chris Katko via Digitalmars-d-learn wrote:
> inside a static foreach I can do
>
> ```
> enum rep;
>
> class myObject{
> int field1, field2, field3;
>
> static foreach(field; getSymbolsByUDA!(typeof(this), rep))
> {
>   pragma(msg, field);  // fails
>   pragma(msg, fullyQualifiedName!field); // works
> }
> }
> ```
>
> error for pragma(msg, field)
> ```
> source/app.d(33,16): Error: value of `this` is not known at
> compile time
> source/app.d(33,4):        while evaluating `pragma(msg, field)`
>
> [repeating for every variable in the class]
> ```
>
> How do I get just the field name? And why does it think this is a run-time value? I need to wrap it in some sort of template?
>
> All I see in std.traits docs are: fullyQualifiedName mangledName moduleName packageName

Well, on my machine, once the import for std.traits is added, that code compiles but prints nothing, so I suspect that you paired it down too much (likely related to the fact that none of the fields in question actually have UDAs on them).

However, I would point out that getSymbolsByUDA gives you symbols, not strings, whereas pragma(msg, ...) wants a string. fullyQualifiedName works, because it results in a string. You can see what field is by using typeof on it, but presumably, it's complaining about being a runtime value, because when you use it, it's trying to evaluate the symbol (e.g. get the value of field1). Using .stringof on field will give you a string, though I don't know if it'll give you what you're looking for. In general, FieldNameTuple would probably be what you would want for getting the names of the fields in a struct or class, though obviously, that wouldn't be just getting the ones with a specific UDA.

- Jonathan M Davis

On Tuesday, 27 June 2023 at 04:25:13 UTC, Chris Katko wrote:
> How do I get just the field name?

__traits(identifier, field)

> And why does it think this is a run-time value?

It is the same as if you wrote `Class.field`

On Tuesday, 27 June 2023 at 22:20:22 UTC, Chris Katko wrote:
> 		pragma(msg, t.stringof); // does not see any new fields!

D's declarations are all order-independent, in theory those foreaches are done simultaneously, so it is kinda a race condition.

In practice, the compiler does them in two passes but both based on the same initial state.

Adding stuff and then reflecting over the stuff you add must be done as explicit steps on the outside, like you can make a `struct step1 {}` then `alias step2 = transform!step1;` then `alias step3 = transform_again!step2;` or something.

On Tuesday, 27 June 2023 at 22:34:17 UTC, Adam D Ruppe wrote:
> On Tuesday, 27 June 2023 at 22:20:22 UTC, Chris Katko wrote:
>> 		pragma(msg, t.stringof); // does not see any new fields!
>
> D's declarations are all order-independent, in theory those foreaches are done simultaneously, so it is kinda a race condition.

Thank you, that's what I thought, but then I started adding them and there was no warning and I was like "wait... is this top-down???"

>
> In practice, the compiler does them in two passes but both based on the same initial state.
>
> Adding stuff and then reflecting over the stuff you add must be done as explicit steps on the outside, like you can make a `struct step1 {}` then `alias step2 = transform!step1;` then `alias step3 = transform_again!step2;` or something.

Okay again makes more sense. The amount of stuff that was "kinda" working, plus learning through tiny 3 liner code snippets in docs, was making my brain explode a bit.

A constructor/factory pattern for this makes way more sense.

Sometimes it's hard to tell where things are symbolic / functional, verses procedural/linear.