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.
