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

[Yuxuan Shui]

On Sunday, 20 May 2018 at 14:39:28 UTC, Jonathan M Davis wrote:
> Well, constructors are one of the few places that the compiler 
> attempts flow analysis for stuff other than optimization, 
> because it pretty much has to in order to do what the language 
> needs. And no, it's not very sophisticated about it, because 
> it's simpler to guarantee correctness that way. It also 
> highlights why Walter is usually against doing much in the way 
> of flow analysis. By designing the language such that it 
> doesn't need much flow analysis, you mostly avoid problems like 
> this. Unfortunately, it becomes more or less impossible to 
> completely avoid it in constructors when you have const or 
> immutable members, so the compiler does have to do some flow 
> analysis in constructors. And it seems that Walter's solution 
> in this sort of situation is to err on the side of having the 
> compiler be stupid in order to avoid better guarantee 
> correctness.
>
> Not being a compiler expert, I can't really comment on what the 
> best approach would be here, but I know that Walter is 
> typically against flow analysis at the semantic pass level 
> precisely because it's very hard to get right, and it's always 
> a battle between having it be sophisticated enough to not get 
> in the programmers way and having it actually be guaranteed to 
> be correct. As I understand it, flow analysis in stuff like the 
> optimizer is _much_ easier, because the constructs you're 
> dealing with are much easier. That's also why Walter and Andrei 
> really like to design advanced language features in terms of 
> lowering into simpler features (e.g. the use of destructors and 
> scope statments all get lowered to try-catch-finally blocks). 
> It's much easier to guarantee correctness with simpler features.
>
> As for this particular case, I expect that the best course of 
> action is to report it in bugzilla and see what Walter thinks 
> is the best approach. I can comment on Walter's basic approach 
> and reasoning based on what he's said about these issues in the 
> past, but I can't way what his response would be to this 
> particular example.
>
> - Jonathan M Davis

I would argue that the best approach is to design the language to 
avoid flow analysis as much as possible. But for places that need 
it, the compiler should do as best as it can.