Le 17/12/2011 02:39, Andrei Alexandrescu a écrit :
On 12/16/11 6:54 PM, Jonathan M Davis wrote:
By contrast, we could have a simple feature that was explained in the
documenation along with static constructors which made it easy to tell
the
compiler that the order doesn't matter - either by saying that it doesn't
matter at all or that it doesn't matter in regards to a specific
module. e.g.
@nodepends(std.file)
static this()
{
}
Now the code doesn't have to be redesigned to get around the fact that
the
compiler just isn't smart enough to figure it out on its own. Sure,
the feature
is potentially unsafe, but so are plenty of other features in D.
That is hardly a good argument in favor of the feature :o).
One issue that you might have not considered is that this is more
brittle than it might seem. Even though the dependency pattern is
"painfully obvious" to the human at a point in time, maintenance work
can easily change that, and in very non-obvious ways (e.g. dependency
cycles spanning multiple modules). I've seen it happening in C++, and
when you realize it it's quite mind-boggling.
The best
situation would be if the compiler was smart enough to figure it out for
itself, but barring that this definitely seems like a far cleaner
solution than
having to try and figure out how to break up some of the
initialization code
for a module into a separate module, especially when features such as
immutable and pure tend to make such separation impossible without
some nasty
casts. It would just be way simpler to have a feature which allowed
you to
tell the compiler that there was no dependency.
I think the only right approach to this must be principled - either by
CTFEing the constructor or by guaranteeing it calls no functions that
may close a dependency cycle. Even without that, I'd say we're in very
good shape.
Andrei
Very good point. CTFE is improving with each version of dmd, and is a
real alternative to static this(); It should be considered when
apropriate, it has many benefices.
