The in/out features come into their own when inheritance is in play, i.e. for me...

1718627440 · 2025-07-03T08:18:14 1751530694

> struct Tag { ... } Tag;

What's the thing with the syntax? If you don't intend to use the type elsewhere don't give it a tag, if you want, you have to give it a name. (Assuming you are annoyed by the duplicate Tag)

WalterBright · 2025-07-04T16:29:41 1751646581

Which would you prefer:

    struct Tag { ... }

or:

    typedef struct Tag { ... } Tag;

? It's just simpler and easier to write code in D than in C/C++. For another example, in C/C++:

    int foo();
    int bar() { return foo(); }
    int foo() { return 3; }

The D equivalent:

    int bar() { return foo(); }
    int foo() { return 3; }

1718627440 · 2025-07-04T21:38:51 1751665131

If the user of Tag is supposed to know how the internal details:

    struct Tag { ... };

if it needs to rely on the internals, but the user shouldn't care:

    typedef struct { ... } Tag;

if it can be opaque (what I would default to):

    typedef struct {} Tag;

I also think that is a good feature to separate specification from implementation, I like being forced to declare first what I want to implement. Funnily in your special case you wouldn't need the declaration. (But of course it's a bad idea to rely on this "feature")