Bug 14666, can we prioritize ?

[deadalnix via Digitalmars-d]

On Wednesday, 10 June 2015 at 06:55:43 UTC, Walter Bright wrote:
> On 6/9/2015 10:39 PM, deadalnix wrote:
>> The actual code is far more complex than the presented sample 
>> :)
>>
>> That what I'm trying to do in general, but here I'm faced with 
>> cases that are
>> very hard to untangle.
>
> The 'tangle' of cyclical import graphs, as you so appropriately 
> put, is not only hard on the compiler, it makes it much harder 
> for human readers to make sense of code. Even reading your 
> little code snippet hurts my brain.
>
> Go, in one of their better decisions, decided "Thou Shalt Not 
> Have Import Cycles". This forces users to untangle their code, 
> and I believe that is A Good Thing.
>
> I'd like to do that for D, but of course it is far too late for 
> that.

That wouldn't be possible. For the most part, the cases where I 
have these kind of thing are due to mixin being non hygienic, 
forcing to import thing I should have been passing via template 
argument.

A typical example of that in SDC is the way types are handled.

SDC has AST and IR, which share some common feature when it comes 
to type, but are also different. There is a module that implement 
the common feature for IR types and AST types.

Problem is, this base uses bitfield from the standard lib, which 
in turn uses mixin. Meaning I can't use the base with importing 
all modules where it is going to be instantiated. This in turn 
cause the forward reference thing and forces me to bypass the 
type system in various places to avoid it.

This means either make Liskov very sad and create a 'tangle' with 
imports, or just not use the standard lib and duplicate a ton of 
code.