...that I come up across metaprogramming problems that can't be easily Googled and making bug reports for is hard?

https://issues.dlang.org/show_bug.cgi?id=20072

I tried upgrading to 2.087.0 and got blindsided by an error that looks something like:

no property `somevar` for type `some.Type`, did you mean `some.Type.__anonymous.somevar`?

Writing some entirely unrelated code earlier using 2.086.1 got a similar error and finally twigged me to the fact that it is actually static foreach problem.

This highlights one of the other things I don't like when errors like this happens: D's quality of error messages is still not great. They've most definitely improved since DDMD happened, but they still seem predicated on the idea that people aren't going to be doing a lot of metaprogramming and provide almost no context when you're deep down the meta hole.

At least now that I know what the hey is going on, I can actually work at upgrading to 2.087.0 with a workaround, but that legit was going to block me from ever upgrading.

live code link: https://run.dlang.io/is/PBKQ80

example code direct:

import std.meta : AliasSeq;
import std.traits : moduleName;

string generateFor( string objectName )()
{
    return "struct " ~ objectName ~ "{ }";
}

alias StructNames = AliasSeq!( "StructOne", "StructTwo", "StructThree" );

static foreach( Name; StructNames )
{
    mixin( generateFor!Name );
}

pragma( msg, moduleName!StructOne );

On Tuesday, 23 July 2019 at 18:36:19 UTC, Ethan wrote:
> This highlights one of the other things I don't like when errors like this happens: D's quality of error messages is still not great. They've most definitely improved since DDMD happened, but they still seem predicated on the idea that people aren't going to be doing a lot of metaprogramming and provide almost no context when you're deep down the meta hole.

That's how metaprogramming oriented languages are. Every language that has advanced metaprogramming like C++ or D sooner or later ends up in template spaghetti. Sure, the error messages are nice for simple templates, and performance is nice too, but once you have several generic types and then use them together, good luck, both on errors and compilation speed time. Oh and autocomplete breaks too because most of the code doesn't exist until build time.

On Tuesday, 23 July 2019 at 19:56:44 UTC, JN wrote:
> That's how metaprogramming oriented languages are. Every language that has advanced metaprogramming like C++ or D sooner or later ends up in template spaghetti.

Perhaps you're not familiar with MSVC's template error messages of late? Those things are tight.

It's not an unsolvable problem. It's just not a problem that will serve a lot of people right now.

On 23.07.19 20:36, Ethan wrote:
> ...that I come up across metaprogramming problems that can't be easily Googled and making bug reports for is hard?
> 
> https://issues.dlang.org/show_bug.cgi?id=20072
> 
> I tried upgrading to 2.087.0 and got blindsided by an error that looks something like:
> 
> no property `somevar` for type `some.Type`, did you mean `some.Type.__anonymous.somevar`?
> 
> Writing some entirely unrelated code earlier using 2.086.1 got a similar error and finally twigged me to the fact that it is actually static foreach problem.
> 
> This highlights one of the other things I don't like when errors like this happens: D's quality of error messages is still not great. They've most definitely improved since DDMD happened, but they still seem predicated on the idea that people aren't going to be doing a lot of metaprogramming and provide almost no context when you're deep down the meta hole.
> 
> At least now that I know what the hey is going on, I can actually work at upgrading to 2.087.0 with a workaround, but that legit was going to block me from ever upgrading.
> 
> live code link: https://run.dlang.io/is/PBKQ80
> 
> example code direct:
> 
> import std.meta : AliasSeq;
> import std.traits : moduleName;
> 
> string generateFor( string objectName )()
> {
>      return "struct " ~ objectName ~ "{ }";
> }
> 
> alias StructNames = AliasSeq!( "StructOne", "StructTwo", "StructThree" );
> 
> static foreach( Name; StructNames )
> {
>      mixin( generateFor!Name );
> }
> 
> pragma( msg, moduleName!StructOne );

This shouldn't happen (the anonymous scope is an implementation detail and `__traits(parent, ...)` shouldn't return it, especially not for symbols that are not even `static foreach` loop variables). Is there already an issue for this? Also, this code compiles neither with 2.086.1 nor 2.087.0. Do you have an example that demonstrates a regression?

On 24.07.19 02:51, Timon Gehr wrote:
> Is there already an issue for this?

Just noticed that the linked issue conflates both problems. I don't think that the visibility bug is the same as the `__traits(parent, ...)` one.

On Wednesday, 24 July 2019 at 00:51:35 UTC, Timon Gehr wrote:
> This shouldn't happen (the anonymous scope is an implementation detail and `__traits(parent, ...)` shouldn't return it, especially not for symbols that are not even `static foreach` loop variables). Is there already an issue for this? Also, this code compiles neither with 2.086.1 nor 2.087.0. Do you have an example that demonstrates a regression?

The entire point of that code I posted and the bug report I made is *to illustrate* that static foreach is broken. *OF COURSE* it shouldn't happen.

And it shouldn't be this hard for an end user to work out what the problem is.

2.086.1 and 2.087.0 are the versions I've been developing on. Take the code, run it in prior DMDs. You'll find where it broke. I legit just pasted it in to godbolt and clicked on prior LDCs, it's been there as long as LDC has supported static foreach (ldc 1.6.0 based on dmd 2.076.1)

Herringway on IRC even made a version without dependencies:

static foreach( Name; [""] )
{
    struct StructOne {}
}

struct Z {
    static foreach( Name; [""] )
    {
        struct StructOne {}
    }
}
pragma(msg, __traits(parent, StructOne).stringof);
pragma(msg, __traits(parent, Z.StructOne).stringof);

On Wednesday, 24 July 2019 at 01:06:18 UTC, Ethan wrote:
>

It's 4am and I was planning on having a major feature finished 8 hours ago, but I've been running in to static foreach and mixin bugs all day.

On Wednesday, 24 July 2019 at 01:10:34 UTC, Ethan wrote:
> On Wednesday, 24 July 2019 at 01:06:18 UTC, Ethan wrote:
>>
>
> It's 4am and I was planning on having a major feature finished 8 hours ago, but I've been running in to static foreach and mixin bugs all day.

https://issues.dlang.org/show_bug.cgi?id=20079
https://issues.dlang.org/show_bug.cgi?id=20080

........and when trying to get to sleep, I decided to try forward declarations for the functions I was having issues with in mixins. And finally hit upon what I think are the root problems I've been having.

Mixin templates have been broken in one way or another since I started using D in 2012. This static foreach bug I've found just seems to highlight to me that the method of defining a separate scope and importing in to the parent after the fact just plain doesn't work.

On 24.07.19 03:06, Ethan wrote:
> On Wednesday, 24 July 2019 at 00:51:35 UTC, Timon Gehr wrote:
>> This shouldn't happen (the anonymous scope is an implementation detail and `__traits(parent, ...)` shouldn't return it, especially not for symbols that are not even `static foreach` loop variables). Is there already an issue for this? Also, this code compiles neither with 2.086.1 nor 2.087.0. Do you have an example that demonstrates a regression?
> 
> The entire point of that code I posted and the bug report I made is *to illustrate* that static foreach is broken. *OF COURSE* it shouldn't happen.
> ...

As I am sure you are aware, this practice is called confirming a bug report. Not all of the issues you opened are in fact compiler bugs. Some of them are you misunderstanding the language specification.

I asked whether you can demonstrates a regression because you said the problem arose when you updated compilers, but it seems it's because some deprecation period ended.

On Wednesday, 24 July 2019 at 02:12:53 UTC, Ethan wrote:
> On Wednesday, 24 July 2019 at 01:10:34 UTC, Ethan wrote:
> but I've been running in to static foreach and
>> mixin bugs all day.
>
> https://issues.dlang.org/show_bug.cgi?id=20079
> https://issues.dlang.org/show_bug.cgi?id=20080

Those are by design and it is a fairly useful design too. The presence of a name in the outer scope overrides the same name from the mixin. This allows easy selective customizing of a mixin template as you use it.