Re: pragma msg field name?
On 6/27/23 6:34 PM, 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. In particular the practice of adding new members based on introspecting other members is suspect. I've done it too, but I think it probably would be better if we didn't allow this kind of stuff, or came up with a sane way to do this. This leads to all kinds of weird stuff. Like if you instantiate a template with the current type being compiled, that template is locked to that type *at that point in compilation*. Then you look at it outside the type, and the value is already cached. -Steve
Re: pragma msg field name?
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.
Re: pragma msg field name?
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.
Re: pragma msg field name?
Does anyone know why the new variables don't show up after the
static foreach?
I have a struct, it has some marked fields. I want to note those
fields at compile time and make some similarly named fields like
myField becomes myField__replicated.
The code doesn't _have_ to be inside the struct/class itself. It
could be:
```
auto replicatedObject = makeReplicated!(myObject);
```
for example.
I'm not sure the high-level best way right now, as I'm currently
having issues with the nitty-gritty implementation of templates.
snippetcode (drop right into run.dlang.io):
```D
import std;
struct multiplayerObject2
{
ushort type;
ushort type2;
float x, y;
static foreach(t; typeof(this).tupleof)
{
pragma(msg, t.stringof);
mixin("bool " ~ t.stringof ~ "25;"); // copy the fieldname with
a suffix
}
pragma(msg, "-separator-");
static foreach(t; typeof (this).tupleof) // again
{
pragma(msg, t.stringof); // does not see any new fields!
}
}
void main()
{
}
```
```D
// Output
type
type2
x
y
-separator-
type
type2
x
y
```
Re: pragma msg field name?
On Tuesday, 27 June 2023 at 05:03:01 UTC, Jonathan M Davis wrote: However, I would point out that getSymbolsByUDA gives you symbols, not strings, whereas pragma(msg, ...) wants a string. For some time now, it accepts any number of objects, which will all be converted to strings and concatenated to form the message. The same applies to `static assert()`.
Re: pragma msg field name?
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`
