Any way to override base type with dervived in derived type

[IntegratedDimensions]

On Friday, 25 May 2018 at 10:45:23 UTC, Steven Schveighoffer 
wrote:
> On 5/24/18 4:24 PM, IntegratedDimensions wrote:
>
>> What I'd like to do is
>> 
>> class C : A
>> {
>>     private override @property TT t() { return cast(TT)(_t); } 
>> // null check if necessary
>>     // Stuff below uses t which is now a TT
>>     ...
>> }
>
> It should work, you are allowed covariant overloads. However, 
> private functions are not virtual, you need to make them at 
> least protected.
>
> -Steve

So, I upgraded everything, tried to add the setter and get an 
compile time access violation:


override @property T t(T v) { _t = v; return v; }

Changing T v to TT v gives the violation

override @property T t(TT v) { _t = v; return v; }


object.Error@(0): Access Violation
----------------
0x004850C8
0x00485C96
0x0043E22A
0x0047FB50
0x0046109A
0x0052401A
0x77D0B605 in LdrQueryProcessModuleInformation
0x77D11D02 in RtlQueryProcessLockInformation
0x77D11705 in RtlQueryProcessDebugInformation
0x77CA47DF in RtlAllocateHeap

While my specific use case is far more complex in design, the 
original essentially boils down to the dpaste I gave. Probably 
won't spent any time on it since I do not need the setter in this 
case(can use the field directly). But a bug is probably related 
to the code that fixed the "original bug" and possibly windows. 
What I do know is that 2.75 did not produce this access violation 
and it was the same code(I just uncommented out the setter).

The original dpaste code that did pass, I though, doesn't seem to 
pass now. I thought it was working for 2.80 and so I changed it 
to 2.69 and it failed but I might have made a mistake or the page 
lagged.

Either way, maybe you have a clue for future reference.