* "At the AliasThis declaration semantic stage, the compiler
can
perform the initial checks and reject the obviously incorrect
AliasThis declarations." -> it might be simpler (for the sake
of
simplifying generic code) to just delay all error checking to
the
first use.
I disagree with that. Current check is not recursive and
prevent you
code from a silly errors:
struct X(T, V)
{
T t;
V v;
alias t this;
alias v this; //Error if is(T == V). However this code is
fundamentally broken, and this error should be raised as soon
as possible.
}
The code is not fundamentally broken if alias this is never
used. I agree rejecting the code compulsively is also sensible,
ONLY if there is a simple way to write a static if condition to
make the code work. Meaning:
struct X(T, V)
{
T t;
V v;
static if (please_fill_this)
alias t this;
static if (please_fill_this_too)
alias v this;
}
If the two conditions are too hard to write then it would be
difficult to argue this point successfully.
This code can be rewritten as:
struct X(T, V)
{
T t;
V v;
alias t this;
static if (!is(V == T))
alias v this;
}
The code is not fundamentally broken if alias this is never
used.
I meant that when you say that X is a subtype of T and X is a
subtype of V where you don't know what T and V are, it means you
don't really know what you're doing. And that is an error and the
compiler should inform you about it as soon as possible. However
I may be mistaken.
Understood. All: okay to make alias this + opDispach applicable
to the
same expression an error?
I think it will be nice.
I'm sending this now with these points, will make one more pass
through
the DIP when I'm online again.
Ok, I'll wait.
And please, answer the question about the is-expression.
