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