DIP66 v1.1 (Multiple) alias this.
IgorStepanov via Digitalmars-d
digitalmars-d at puremagic.com
Mon Nov 3 07:39:41 PST 2014
>>> * "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.
More information about the Digitalmars-d
mailing list