Can now use alias for collapsing multiple fields in nested structs (page 2)

On Sunday, 29 December 2024 at 21:08:39 UTC, Walter Bright wrote: > On 12/29/2024 8:23 AM, Timon Gehr wrote: >> Works in my frontend, does not work with DMD: > > Oh, how I wish you'd make PRs for DMD! A nice expansion of alias! I tested it out below with some more nesting to see if it worked -- and it did :) ``` import std.stdio; import std.conv; struct Type{ struct Nested1{ Nested2 s; struct Nested2{ int t; } } // A field in our type for testing purposes Nested1 field; // alias to a struct member -- 'another name' to conveniently access // fields. // This is the main feature I am demonstrating // i.e. alias to a struct member. alias innerT = field.s.t; } void main(){ // Create an instance of our type Type test; // Access member variable conveniently through alias. test.innerT= 42; // Assert we are accessing the correct value assert(test.field.s.t == 42); // Write out the result string value = i"$(test.field.s.t)".text; writeln(value); } ```

On Saturday, 28 December 2024 at 19:21:43 UTC, Walter Bright wrote: > > `alias` has evolved from simply `typedef` into quite the multi-tool! > > https://github.com/dlang/dmd/pull/20611 > > Manu suggested this. Well done!

On Saturday, 28 December 2024 at 19:21:43 UTC, Walter Bright wrote: > It's commonplace in C and C++ to use something like: > > ``` > #define ti t.i > > s.ti > ``` > as a shortcut for cutting through layers of struct declarations. Now `alias` can do it, too! > > This now works: > > ``` > struct T { > int k,i = 2; > } > > struct S { > int x; > T t; > alias ti = t.i; > } > > void main() { > T t = T(1, 2); > S s; > assert(s.ti == 2); > } > ``` > > `alias` has evolved from simply `typedef` into quite the multi-tool! > > https://github.com/dlang/dmd/pull/20611 > > Manu suggested this. Excellent! I should start posting things as Manu if I want anything to get done 😅 https://github.com/dlang/dmd/issues/17760 -Steve

December 30

Re: Can now use alias for collapsing multiple fields in nested structs

Posted by Derek Fawcus
in reply to ryuukk_

Permalink

Derek Fawcus

Posted in reply to ryuukk_

Permalink

On Monday, 30 December 2024 at 12:08:53 UTC, ryuukk_ wrote:

On Sunday, 29 December 2024 at 04:10:13 UTC, Walter Bright wrote:

On 12/28/2024 5:23 PM, Derek Fawcus wrote:

It was... That particular preprocessor game largely became unnecessary once we gained C11 anonymous structs and unions.

D had anonymous structs and unions long before C11.

but D can't do that

Yeah - the C usage, is something like this:

#ifdef C89_STYLE
struct Outer {
	int o_x;
	struct {
		int i_a;
		int i_b;
 	} s;
};
#define o_a s.i_a
#define o_b s.i_b

#else /* C89_STYLE */

struct Outer { /* C11 Style */
	int o_x;
	struct {
		int o_a;
		int o_b;
 	};
};
#endif /* C89_STYLE */

struct Outer os;
void foo(void) {
	os.o_x = 1; os.o_a = 2; os.o_b = 3;
}

Whereas this new D enhancement seems to be somewhat different, as in D it seems the structs always need to have tags.

Not that I'm arguing against such an enhancement; simply that the C limitation, and preprocesser games being used as a partial justification is long obsolete.

On 12/29/24 22:08, Walter Bright wrote: > On 12/29/2024 8:23 AM, Timon Gehr wrote: >> Works in my frontend, does not work with DMD: > > Oh, how I wish you'd make PRs for DMD! > Me too. I created that frontend back when I was a student with a lot of spare time. Well, hopefully we can at least get the unpacking syntax over the finish line soon. (Only thing that's really left to be done is fixing some fail-compilation test failures.)

On Monday, 30 December 2024 at 22:22:27 UTC, Timon Gehr wrote: > On 12/29/24 22:08, Walter Bright wrote: >> On 12/29/2024 8:23 AM, Timon Gehr wrote: >>> Works in my frontend, does not work with DMD: >> >> Oh, how I wish you'd make PRs for DMD! >> > > Me too. I created that frontend back when I was a student with a lot of spare time. > > Well, hopefully we can at least get the unpacking syntax over the finish line soon. (Only thing that's really left to be done is fixing some fail-compilation test failures.) So can one take it that your alternate front end is still a long way from being usable as an alternate for say LDC or GDC? Or is it closer?

On 12/30/24 23:45, Derek Fawcus wrote: > On Monday, 30 December 2024 at 22:22:27 UTC, Timon Gehr wrote: >> On 12/29/24 22:08, Walter Bright wrote: >>> On 12/29/2024 8:23 AM, Timon Gehr wrote: >>>> Works in my frontend, does not work with DMD: >>> >>> Oh, how I wish you'd make PRs for DMD! >>> >> >> Me too. I created that frontend back when I was a student with a lot of spare time. >> >> Well, hopefully we can at least get the unpacking syntax over the finish line soon. (Only thing that's really left to be done is fixing some fail-compilation test failures.) > > So can one take it that your alternate front end is still a long way from being usable as an alternate for say LDC or GDC? > > Or is it closer? It is relatively incomplete and does not compile with official DMD releases that are newer than 2.060. This is because I used too much metaprogramming. Rainer had a patch for DMD 2.073.0, but it broke other projects. https://github.com/tgehr/d-compiler The test suite should give some indication what it can do: https://github.com/tgehr/d-compiler/tree/master/test It has Turing complete templates and has relatively fast CTFE using a byte code interpreter, but is missing a lot of the bells and whistles. Also, it is a frontend only so far, no backend code generator (other than for the CTFE byte code).

On 12/30/2024 2:22 PM, Timon Gehr wrote: > On 12/29/24 22:08, Walter Bright wrote: >> On 12/29/2024 8:23 AM, Timon Gehr wrote: >>> Works in my frontend, does not work with DMD: >> >> Oh, how I wish you'd make PRs for DMD! >> > > Me too. I created that frontend back when I was a student with a lot of spare time. Is your frontend based on dmd or is it ground up?

Forums