On 5/20/18 6:56 AM, Yuxuan Shui wrote:
On Sunday, 20 May 2018 at 00:05:39 UTC, Jonathan M Davis wrote:
because it tends to become very difficult to get right in all cases
and results in situations where the programmer is forced to do
something in order to make the compiler shut up
Well, doesn't this post show exactly this problem, and that's because
the compiler is too dumb?
Making the compiler smarter will only decrease the number of these cases.
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.
2. No matter how smart you make the compiler, you will get into
situations that it can't figure out (halting problem). 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.
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.
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.
-Steve
