On Thu, 28 May 2009 15:02:06 -0400, Ary Borenszweig <a...@esperanto.org.ar>
wrote:
Steven Schveighoffer wrote:
On Thu, 28 May 2009 14:23:48 -0400, Ary Borenszweig
<a...@esperanto.org.ar> wrote:
Steven Schveighoffer wrote:
On Thu, 28 May 2009 13:59:10 -0400, Ary Borenszweig
<a...@esperanto.org.ar> wrote:
Is there something wrong in my reasoning?
It's just that you aren't always compiling every file at the same
time...
Static this' implementation isn't part of the public interface, so it
might not even *be* in the import file (if it's a .di file).
So it should be in the .di file.
Where do
you throw the compiler error, if you can't determine the circular
reference at comiple time?
You don't throw the error and that's it. What's the worse thing that
could happen? A bug in the code. You go and you fix it. If there's no
bug in the code and the compiler yells at you, that's very annonying
(like in the example you showed).
A bug like this could be very subtle, you may not know the order
static this' are executed. Worse than that, simply importing another
module could affect the order, and that might make an unrelated bug
that previously was hidden suddenly show up.
I think with the import system the way it is, the only safe prospect
is to have it error like it does now. You either need some
attribution like has been suggested in this thread (and have the
compiler verify that attribution), or change the import system.
I still can't see what's the problem if the error were not issued by
the compiler and static this would be run in the order defined by
dependencies found in static ifs.
I assume you mean static this'?
Yes. :-P
Until I see a real example where if the compiler doesn't issue an
error then something *really bad* would happen, then I won't be able
to give much more opinion about this. :-(
What about this (bear with me, lots of files here):
f1.d:
private import f2;
int x;
static this()
{
x = y;
}
f2.d:
private import f3;
int y;
static this()
{
y = z;
}
f3.d:
private import f1;
int z;
static this()
{
z = x;
}
Now, the compiler has to obey 3 rules: f1 depends on f2, f2 depends on
f3, f3 depends on f1.
Oops, there's a cycle, but we can detect that, right?
What if you are importing .di files:
f2.di:
int y;
static this();
Now, how do you know when compiling f1 that it depends on f3, and f3
depends on f1? The cycle is hidden because the compiler can't look at
the compiled end result for each source file.
This is similar to the "how come the compiler can't automatically
decide what's const and what's not" debate. Unless the compiler is
allowed to generate metadata from files that it can feed back into
itself later, these kinds of things are impossible without manual
annotation.
I realize the end result of my example is pretty innocuous, but
imagine that you are trying to use an object you expect to be
instantiated by a static this function, only to find that it's null.
I'd rather see a "circular import" error than a segfault that all of a
sudden shows up because someone used my library differently.
Thanks for the example.
That's why I suggest that di files should contain the code of the static
this. Some functions in di files include their source code (I don't know
what's that rule, but I just tried it and it did it), and this might not
be important, but static this are important...
.di files are not always auto-generated. They can be hand-edited to
remove implementation (druntime's object.di is such a file).
The only problem left I see is how the compiler defines the order of
execution of static this. If there are no circularities then there's no
problem. If there is circularity, then it might be caught by the logic I
proposed. If it isn't caught at this point, and, as you said, there's a
bug and you'd get a segfault, then you'd get it as soon as you run your
code, which is exactly the same logic as now, but it gives programmers
more freedom to write their code as they want.
A segfault might not be the result. Imagine an object constructor that
uses another object, but if you pass in null it does something else
besides segfaulting.
-Steve
