SOOOOOO

Since not many liked the idea of static assert behaving correctly (note for reference that C++'s static_assert will not stop compilation in at least MSVC and will give you all the error information you need), here's another example that's currently driving me up the wall.

Error: template instance `AliasSeq!( ... )` recursive template expansion

This one's the result of trying to compile my code in LDC. Symbols omitted because they're not important.

What is the important part? As a part of dealing with "recursive template expansion" last time the compiler didn't want to give me information, I determined that an AliasSeq will give that error if something fails to compile.

While tracking down another error, I discovered that LDC has issues with cross-module visibility and alias this. This code compiles just fine in online compiler testers:

struct Something
{
    enum Val = 5;
    int dummy;
}

struct SomethingElse
{
    Something derp;
    alias derp this;
}

pragma( msg, SomethingElse.Val.stringof );

But put it across modules (and, in my case, template the equivalent of SomethingElse) and things start going wrong in LDC.

Which leads me to the recursive expansion. Because whatever's going on wherever in my code, the compiler knows there's a problem and is refusing to tell me.

This code should have been compiling hours ago, and I should have been uploading this binary not long after.

These instances of the compiler stopping have cost me too much time. Counter arguments to this are just plain incorrect. Any given compiler *needs* to tell the user *why it's not compiling code*.

As it stands, it's a crapshoot hand-auditing about 10,000 lines of heavily templated D code right now trying to find out what the actual problem is. This is neither a fun nor entertaining nor productive use of my time.

On Tuesday, 13 August 2019 at 21:00:38 UTC, Ethan wrote:
> Which leads me to the recursive expansion. Because whatever's going on wherever in my code, the compiler knows there's a problem and is refusing to tell me.

Finally compiling and linking.

Whatever the problem is, it's not liking circular imports in my code.

Not that it bothered to tell me that.

On Tuesday, 13 August 2019 at 22:36:09 UTC, Ethan wrote:
> On Tuesday, 13 August 2019 at 21:00:38 UTC, Ethan wrote:
>> Which leads me to the recursive expansion. Because whatever's going on wherever in my code, the compiler knows there's a problem and is refusing to tell me.
>
> Finally compiling and linking.
>
> Whatever the problem is, it's not liking circular imports in my code.
>
> Not that it bothered to tell me that.

Circular imports and circular dependencies have always been a minefield. They *work*, sort of, but not always reliably. A whole bunch of bugs have taken the form "I've used a circular dependency to confuse the compiler into treating a type as finished when it wasn't actually done figuring it out yet", especially around concepts like inspecting a type from a mixin template inside the type, and things like that.

As a language, D is always torn between "I want to take on big challenges and become more powerful!" and "Why did I do that! I regret that decision immediately!" Unfortunately, it's very hard to say "no, we've bit off too much complexity here, we should forbid this kind of construct." The temptation will always be to say "let's just focus on this next bug, this feature can work if we just fix all the issues with it" and ignore the fact that this many issues are a warning sign that a feature doesn't fit cleanly into the rest of the design.

On Wednesday, 14 August 2019 at 06:50:11 UTC, FeepingCreature wrote:
> especially around concepts like inspecting a type from a mixin template inside the type, and things like that.

The first time I tried something similar like that, I thought it will never compile. To my amazement it did. I still don't fully understand how it works, but I am glad it does.

On Wednesday, 14 August 2019 at 10:04:58 UTC, Sebastiaan Koppe wrote:
> On Wednesday, 14 August 2019 at 06:50:11 UTC, FeepingCreature wrote:
>> especially around concepts like inspecting a type from a mixin template inside the type, and things like that.
>
> The first time I tried something similar like that, I thought it will never compile. To my amazement it did. I still don't fully understand how it works, but I am glad it does.

Yep, and I've been bitten before with mixins like that in Binderoo.

But this one. The only reason there was a circular import was to gain access to some struct UDAs.

In this case, I'd have to say "Even C can manage include guards/#pragma once".