Cannot implicitly convert derived type

[Frustrated]

On Sunday, 23 February 2014 at 01:37:08 UTC, Steven Schveighoffer
wrote:
> On Sat, 22 Feb 2014 15:17:37 -0500, Frustrated 
> <c1514843 at drdrb.com> wrote:
>
>> It is legal exactly because I will always guarantee that the
>> proper button will be used.
>
> Static typing says it's not legal. D does not do dynamic type 
> checking upon calling virtual functions.
>
>> It is not logically legal as mentioned several times... no one
>> needs to mention that. But it is legal within the context of 
>> the
>> code. I'll never use a RogueButton so why force me to code for
>> the chance I might?
>
> You may not be the only one using WindowsGui. You can't 
> guarantee other code won't do it. In any case, the compiler 
> cannot possibly know your intentions.
>
>> Basically, the point is, the compiler could enforce the above 
>> but
>> make the code more readable.
>>
>> e.g.,
>>
>> I do this:
>>
>> @property WindowsButton button(WindowsButton b)
>> {
>>
>> }
>>
>> The compiler turns this into
>>
>> @property WindowsButton button(iButton _b)
>> {
>>     if (is(_b : WindowsButton)) assert(0, "Rogue button used");
>>     auto b = cast(WindowsButton)_b;
>>
>> }
>
> This solution is not as efficient as the one I outlined. If you 
> have a WindowsGui object, no need to accept iButton when you 
> require WindowsButton.
>
>> One allows me to program in a natural way while the other makes
>> me jump through hoops which litters the code with a bunch of
>> casts and checks which are only there in the odd event that I
>> assign the wrong type(which, I'm not going to do on purpose).
>
> Sorry, if you want a dynamically typed language, use one. D is 
> not that.
>
>> Again, the whole point of why it is illegal because you can 
>> pass
>> a RogueButton... BUT I DON'T INTEND TO PASS THEM! If I could
>> absolutely guarantee that I won't pass them then there should 
>> be
>> no problem(no asserts). Since I can't guarantee it I have to
>> litter my code with checks? The compiler could do this for me.
>
> You can't guarantee it. That is the point. The compiler could 
> do the checks for you, but D is not dynamically typed. The best 
> you can do is encapsulate the type checking code as a mixin.
>
> -Steve


It has nothing to do with being dynamically typed. We can't solve
this problem until you get your head out of the gutter(the gutter
being how D does things already. Can't make progress on something
if you ever look beyond what it can do).

This has to do with simply adding checks to enforce the type. I
can guarantee it, but like you said, I can't guarantee what
others do. Hence the check.

The fact is, I presented two versions of the code. One represents
the other. It is a representational problem, nothing more,
nothing less. Please understand that from now on.

e.g., a switch statement is just a representational form of if
statements to simplify. I'll I'm talking about is adding a switch
statement. (if you take that literal and can't see how it relates
to the original problem then you are completely missing the point
of the whole discussion)

I did think it might be possible to use CT reflection to generate 
all the type checking automatically but this might be difficult 
and would have to generate a new class. It seems like the only 
way to get at this problem in D.