Our template emission strategy is broken

[James Hofmann via Digitalmars-d]

On Wednesday, 11 November 2015 at 17:19:31 UTC, David Nadlinger 
wrote:
> Of course, many of the problems could have probably been 
> avoided if there was an iron-clad rule that the module 
> dependency graph must remain acyclic from the beginning of 
> development (at least at the level of units of compilation). 
> But how could they have known how bad it would get otherwise? I 
> don't think this is reflected in our documentation anywhere, at 
> least not in a prominent place.
>
>  — David

There is some literature about whether this kind of rule, 
enforced at compile-time, can benefit software architecture in 
general, in the context of F# projects vs. similar C# projects. 
(Answer: probably yes - there's a relationship between cyclical 
dependencies and other accidental coupling; you can make some 
case for it both theoretically and in statistics)

http://evelinag.com/blog/2014/06-09-comparing-dependency-networks/#.VkP6mL_eNYU

Looking at what D does now, at least according to "The D 
Programming Language" (2010), it tries to allow any ordering but 
throws an exception at runtime when ambiguious cases are 
detected. So there's already some precedent to avoid cyclical 
dependency simply to avoid those errors. The coupling argument 
and the compile-times argument just add more urgency to it.

Nim enforced the same dependency rule as F# the last time I 
looked, but I think that position was softening towards 
"optional" due to some community pressure. I don't think anything 
makes this architecture style actually impractical and it might 
help to have the compiler warn towards it - although the same 
kind of community pressure is going to arise if it did do so. 
After all, nobody likes to be told that they are writing Bad Code 
:)