Program size, linking matter, and static this()

[Andrei Alexandrescu]

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