On Thursday, 29 November 2012 at 12:17:49 UTC, Jonathan M Davis
wrote:
Basic features in the language require static constructors
(e.g. static
variables frequently do), and some things just can't be done
without them.
Andrei's std.benchmark proposal actually doesn't work, because
in order to do
what it does, in needs to mixin in a static constructor and
static destructor
(to set up the benchmarking and record it at the end, I
believe). That
completely falls apart due to cyclical imports. It doesn't
actually cause any
true circular dependencies, but it's treated as such anyway. A
_lot_ of us
have run into this problem and a number of us consider it to be
a huge design
problem in the language. Personally, I'd put it towards the top
of design
mistakes at this point, and I'm very glad to see Walter
actually finally being
willing to do something about this. In the past when I've
brought up similar
solutions, he's been completely opposed to them.
Yes, we have other major issues that need to be resolved, and
those may very
well be of a higher priority, but this is still a very import
issue, and it's
the sort of issue that can probably be implemented with minimal
effort. The
main thing is getting Walter to agree to it and how it will be
done. Once a
decision is made, it wouldn't surprise me if someone like Kenji
were able to
get it done very quickly.
- Jonathan M Davis
That is understood, but Let me explain how I see things.
We are here adding yet a new feature, however small. Nothing
stabilize when adding new feature all the time.
The annoyance exist, is real, but is not THAT bad, and 'm pretty
sure the proposed solution is likely to backfire. Firstly because
a module can have several constructors, and more can be added by
mixins. Ensuring that constructor A will not create dependancy
cycle error may silently break other constructor of the module.
Considering the problem static constructor solve, I'd be happy to
see some think out of the box. The way things work here may be
broken. Many people consider that D runtime should evolve in a
way that promote fibers and map them over system threads (this
have many benefit : the program adapt autmatically to the
provided hardware, yields can be introduced directly into the
runtime or some libraries to hide IO latencies, and many other
things), and static constructor/variables really get into the way
(you would have to run all static constructors each time you
start a new fiber or reset one to reuse it).
I really wish we can focus on figuring out the uses cases we have
for static constructor and start the reflection from theses sues
case and not from the feature itself.
