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

Steven Schveighoffer schveiguy at yahoo.com
Mon May 21 20:54:08 UTC 2018


On 5/21/18 4:29 PM, Yuxuan Shui wrote:
> 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?

There are at least two other incomplete front ends. One by deadalnix 
(sdc) and one by Timon Gehr.

But surely, if we got it right in the main front end, such techniques 
could be done in others right? Well, the problem simply is that I don't 
think there is a magic bullet here. We will have situations that are 
clear to a human that all paths call the super ctor, but aren't clear to 
some compilers.

In that case, the language is different based on which compiler you 
might use.

Rather than it be dependent on approximating a solution to an insolvable 
problem, we can simply say the *minimum* is this, and we KNOW that can 
be implemented. In turn, we also know that D gives you the tools to make 
it easy to conform to these requirements.

>> 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.

I know Timon's front end handles a crazy amount of forward references. 
I've sat next to him at previous dconfs and he periodically shows me 
stuff his front end can handle, and it's insane.

But in the meantime, the situation is not straightforward with forward 
references, and I'd fear that opening the gates to more flow analysis 
allowances would continue with those games.

>>
>> 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.

Agreed, it is cool when your compiler tells you bugs like a variable is 
used before it's assigned, etc.

> 
>>
>> 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.

I believe it's due to the goal of "we're going to infer ALL THE TYPES!" 
hitting the reality of actual code that makes it not that simple, or 
exponential performance to really get the answer. Stuff that's painfully 
obvious to you or me is not so obvious to the compiler that has to 
actually prove it.

That being said, I haven't used swift much lately, but I don't remember 
this happening much to me in the recent past. So maybe they have gotten 
better at it or solved it.

-Steve


More information about the Digitalmars-d mailing list