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
