Error about constructor calls in loops/labels, but there are no loops and labels?

[Yuxuan Shui]

My response below might be a little off-topic.

On Monday, 21 May 2018 at 13:06:14 UTC, Steven Schveighoffer 
wrote:
> [snip]
>
> There is something to be said for keeping the compiler dumb:
>
> 1. Dumb is easy to implement, explain, and understand -- if you 
> set the bar low then more compilers will be able to handle the 
> use cases. Having code that compiles with all available 
> compilers is better than something that you need a specific 
> "really smart" compiler to work.

This would have been a fair point if there is more than one 
working D frontend right now. Maybe you are arguing the bar of D 
could be lower? Then the problem of where to draw the line pops 
up again. "Being dumb" couldn't be a goal of the language, right?

> 2. No matter how smart you make the compiler, you will get into 
> situations that it can't figure out (halting problem).

True.

> If you are going to have some situations that it doesn't 
> handle, then it's really just a matter of where to draw the 
> line. D has this problem with forward references -- it's a 
> never ending battle of shuffling things around sometimes. The 
> smarter you get, the more odd and difficult to deal with the 
> cases that won't work become.

I would argue this is not because the compiler is too smart. This 
is because the behavior of the compiler is not pinned down. How D 
resolve forward references is not well documented, so when 
problem occurs you have to guess (or read the compiler source 
code, like a real man) to figure out how to solve it.

>
> With inner functions, it's really easy to satisfy the compiler 
> here. You just have to make a few changes in your code, I don't 
> see it being a huge problem.

Not a huge problem, but certainly a rough edge that might make 
someone think D is an unrefined language.

>
> I've been using Swift in the past few years quite a bit, and it 
> always amuses me when it can't figure out some kind of 
> inference that seems trivial, but it just gives up because the 
> compiler takes too long to determine: "This [one line] 
> statement is too difficult, please split into multiple 
> statements." This is the kind of stuff you would be 
> encountering.

Not sure if this is another case of compiler being not smart 
enough? And the solution seems to be pretty simple here.

>
> -Steve