DIP66 - Multiple alias this

[Steven Schveighoffer via Digitalmars-d]

On 10/12/14 7:16 PM, IgorStepanov wrote:
> On Sunday, 12 October 2014 at 23:02:13 UTC, Steven Schveighoffer wrote:
>> On 10/10/14 6:10 PM, IgorStepanov wrote:

>>> You can write foo(c.shadow); This isn't hard.
>>> Ok, I understood you, let's listen to what others say
>>
>> Right, you can get around it.
>>
>> But the issue here is, that I feel like is(T: U) means (from dlang.org):
>>
>> is ( Type : TypeSpecialization )
>> The condition is satisfied if Type is semantically correct and it is
>> the same as or can be implicitly converted to TypeSpecialization.
>>
>> This means is(C : int) should indicate that C can implicitly convert
>> to int. But in your DIP, it does not. I think this is incorrect.

>
> Hmm. I've written case (my previous post), when returning false from
> is(T: S), where T has many pathes to S is dangerous.

OK, I didn't understand your case before, but I just got it.

I understand what you mean, but this isn't anything new -- one can cause 
weird problems by creating diamond-pattern interfaces also. I do not 
actually think it is dangerous, because one would not leave an error 
call in their code. So for a future change to a library to "mystically" 
make a function start working is not a danger, because said code wasn't 
sitting there broken in the first place.

I will note, that for diamond problem interfaces, the compiler seems to 
take a different track than your DIP:

interface A {}
interface B : A {}
interface C : A {}

class X : B, C {}

static assert(is(X : A));

void main()
{
     A a = new C; // works, not sure if it's B.A or C.A
}

I know this is a different problem -- we aren't pointing at two 
different concrete implementations.

-Steve