On Thursday, 25 September 2025 at 22:11:50 UTC, Steven Schveighoffer wrote:

The "allow struct declarations as template arguments" approach seems pretty simple to add. Did you look into it at all? I agree a general syntax would be more challenging

On Thursday, 25 September 2025 at 20:03:27 UTC, Clouudy wrote:

struct Container {
    struct point1 {
        int x;
        int y;
    }
}

That is already valid code, point1 is a nested type.

On Thursday, 25 September 2025 at 22:11:50 UTC, Steven Schveighoffer wrote:

import std.typecons: Tuple;

struct Container {
    Tuple!(int, "x", int, "y") point;
}

I agree that it's unfortunate that we have to use a template to create a tuple. The solution to that is to add built-in tuples. Then we'll be able to write, for example,

struct Container {
    (int x, int y) point;
}

Built-in tuples also solve this problem.

On Friday, 26 September 2025 at 17:22:55 UTC, Nick Treleaven wrote:

struct Container {
    struct point1 {
        int x;
        int y;
    }
}

Damn you're right. IDK why I keep accidentally doing that.

On Friday, 26 September 2025 at 13:40:25 UTC, Hipreme wrote:

IMO this should potentially be optional if the feature gets adopted. Even if it'd be annoying to access the TypeInfo (as in Construct.point.typeinfo), you may still want it for some use cases. For me, I would need it to be able to serialize these internal structs properly. Maybe it could be included as a compiler switch, or if you want the best of both worlds you could use a pragma or have it automatically check which structs need to have typeinfo.

On Saturday, 27 September 2025 at 16:29:38 UTC, Clouudy wrote:

What about this?:

struct Container {
    struct point is {
        int x;
        int y;
    }
}

On Saturday, 27 September 2025 at 12:36:34 UTC, Paul Backus wrote:

struct Container {
    (int x, int y) point;
}

TBH I think built-in tuples could be a good way of doing simple constructs, but I worry about whether this would work for complex nested types that are layers upon layers deep. Because then it would potentially devolve into LISP-like constructs, which is a massive break from how D reads.

On Saturday, 27 September 2025 at 23:17:21 UTC, Clouudy wrote:

If you have complex nested types that are multiple layers deep, you should probably be separating those layers into their own named structs anyway rather than defining everything inline.

Honestly, even if we had built-in tuples, I would prefer to write your original example like this:

struct Point {
    int x;
    int y;
}

struct Container {
    Point point;
}

Adding additional levels of nesting in order to save a few lines is rarely a good idea.

On Sunday, 28 September 2025 at 00:25:41 UTC, Paul Backus wrote:

I think the example with 'point' is too small to represent a realistic use case for this feature, so I want to provide a real struct example to make it easier to discuss. This code is copied directly from my code which parses a .json file of a font atlas generated by msdf-atlas-gen:

struct FontJson
{
	Atlas atlas;
	struct Atlas
	{
		double size; // pixels per em
		int width;
		int height;
		Grid grid;
		struct Grid
		{
			int cellWidth;
			int cellHeight;
			int rows;
			int columns;
			double originY = 0;
		}
	}

	Metrics metrics;
	struct Metrics
	{
		double ascender = 0;
		double descender = 0;
		double underlineY = 0;
		double underlineThickness = 0;
	}

	Glyph[] glyphs;
	struct Glyph
	{
		int unicode;
		double advance = 0;

		struct PlaneBounds
		{
			double left = 0;
			double top = 0;
			double right = 0;
			double bottom = 0;
		}
		PlaneBounds planeBounds;

		struct AtlasBounds
		{
			double left = 0;
			double top = 0;
			double right = 0;
			double bottom = 0;
		}
		AtlasBounds atlasBounds;
	}

	struct Kerning
	{
		int unicode1;
		int unicode2;
		double advance = 0;
	}
	Kerning[] kerning;
}

I don't think it's too bad currently, but I can see anonymous structs being useful here. I wouldn't replace the structs with tuples though. I also don't really want to flatten the nesting, I like how the nested structs model the json structure very closely, and don't want the structs to be used outside the JSON parsing.