On Friday, 22 January 2021 at 00:59:32 UTC, tsbockman wrote:
> 2) Remove, simplify, or mock up/stub out (like for unit tests) some large chunk of the remaining code in the program, from a part of the program that I *think* is unrelated to the error.
> 3) Re-test the program.
>     a) If the failure goes away, goto (2) and try again by removing a different part of the program.

I should clarify here that when I say "try again" I mean from a backup of the last version of the reduction-in-progress that *did* demonstrate the failure.

On Friday, 22 January 2021 at 00:59:32 UTC, tsbockman wrote:

> Generally, I don't need to know what causes an error in order to produce an MCVE. I have successfully done so on many occasions. It's annoying and slow, but usually very possible.

I know that I have to debug it myself, but if somebody already know this kind of error I would still ask about first since the first message makes no sense. The second error indeed explains whats going on.

Anyway. It was a simple question not a prove that there is a bug in the compiler. You guys confuse a forum post question with a public examination.

The simple answer if any for somebody can just be: "void" can also be the data type if the compiler has problems resolving a symbol by running into a recursion while parsing.

On Friday, 22 January 2021 at 02:18:11 UTC, frame wrote:
> Anyway. It was a simple question not a prove that there is a bug in the compiler.

isCallable is intended to either evaluate to a boolean, or give a clear compile-time error message. Since it did neither of those things for you, I suspect that something is wrong in the D project's code in addition to, or instead of, your code.

> You guys confuse a forum post question with a public examination.

No, we're just used to helping each other get to the bottom of things like this. No one asked you for anything different from what we generally expect of each other in this context. This specific expectation mostly exists because, often, without a self-contained example we *truly don't know how to help you*.

You are of course free to decide that our methods aren't worth your time, but please don't take it personally.

On Friday, 22 January 2021 at 02:43:44 UTC, tsbockman wrote:

> No, we're just used to helping each other get to the bottom of things like this. No one asked you for anything different from what we generally expect of each other in this context. This specific expectation mostly exists because, often, without a self-contained example we *truly don't know how to help you*.

Please stop. I am very thankful for every hint, links to docs, tools etc. But if somebody writes "wasting his time" than it's personally (at least for me). I know it wasn't intend, somebody can have a bad day too but thats not helpful.

It's like asking your mechanican if he can guess what's causing the weird sound in the car and he replies with: why didn't you disassemble your car already?

But discusing about such missteps isn't helpful either and I hate it to discover such a post while searching in the web for a simple hint myself, so I will close this mentally. May someone filter out the necessary information about without wasting time.

On Friday, 22 January 2021 at 03:08:23 UTC, frame wrote:
> It's like asking your mechanican if he can guess what's causing the weird sound in the car and he replies with: why didn't you disassemble your car already?

Cars are mass-produced copies of a relatively small number of rather similar designs, and mechanics' customers *pay them* to understand and fix their cars so that the customers don't have to. By contrast, computer programs are tremendously more diverse than car designs, you are not paying anyone here, and we participate here to pass our skills and knowledge on to others, not just to do their work for them.

Nevertheless, I will use your analogy:

    You: My car shakes when I turn left. What do you think is wrong with it?

    Mechanic: Hard to say. Bring it in to the shop and I'll take a look.

    You: It's a simple question! I shouldn't have to bring it in to the shop.

    Mechanic: Fine. If it was my car, here's how I would go about finding the problem... (Detailed explanation follows.) Do that, and if you still can't tell what's wrong, come back and talk to me again.

    You: That's too much work. This is ridiculous. It's a simple question: just tell me what's wrong with my car!

    Mechanic: Why do you think I can diagnose the problem with *even less information than you have*? If it's so simple, why do you need help?

    You: Rude! I'm outa here...

On Friday, 22 January 2021 at 03:40:40 UTC, tsbockman wrote:
> Cars are mass-produced copies of a relatively small number of rather similar designs, and mechanics' customers *pay them* to understand and fix their cars so that the customers don't have to.

I knew this argument comes...

> Nevertheless, I will use your analogy:
>
>     You: My car shakes when I turn left. What do you think is wrong with it?
>
>     Mechanic: Hard to say. Bring it in to the shop and I'll take a look.

No. It's more that I did say: The board computer message is weird, it points to one of my tires but does not tell me the correct error. The tire seems to be wrecked. There is a scratch - but what could cause it? Someone with expierence (a mechanic) know this kind of error? I kindly ask.

But mechanics do not listen and telling me I need to do an oil change and why it's important.

--

If someone is interested:

I think it's a bug that the compiler cannot handle this recursion correctly. By calling isCallable!S and parsing the structs "alias this" not the complete get() content need to be parsed as only the return type is relevant here - which is already known: T

I have to arrange that the problematic code is not parsed when calling isCallable, so the only solution was a proxy method that switch to get() in runtime to satisfy the compiler, not very pretty, but works:

struct foo(T) {
   alias proxy this;
   T delegate() p;

   // called from this(), this(this)
   void initProxy() {
      p = delegate() { return get; };
   }

   T get() {
     // problematic code
   }

   T proxy() {
     return p();
   }
}