On Monday, 13 October 2014 at 00:54:13 UTC, Steven Schveighoffer
wrote:
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
This is fundamentally different situation: interfaces haven't a
state, thus don't care what interface will be getted: B.C or C.C.
Moreover, we can think that we have only one base C (like virtual
inherited class in C++).
Alias this case requires a completely different approach.
