On Thursday, 24 May 2018 at 20:24:32 UTC, IntegratedDimensions wrote:
> I'm pretty much guaranteed that in C, t will be type TT due to the design(C goes with TT like bread with butter).
...
1) Your architecture is wrong, I recommend to rethink it.
2) You still can deal with it using template mixins https://dlang.org/spec/template-mixin.html

On Saturday, 26 May 2018 at 01:11:39 UTC, crimaniak wrote:
> On Thursday, 24 May 2018 at 20:24:32 UTC, IntegratedDimensions wrote:
>> I'm pretty much guaranteed that in C, t will be type TT due to the design(C goes with TT like bread with butter).
> ...
> 1) Your architecture is wrong, I recommend to rethink it.

Prove it genius! I recommend you rethink your absolutes without having a clue. Go back to SO, they need more Nazi's.

> 2) You still can deal with it using template mixins https://dlang.org/spec/template-mixin.html

I've already said templates do not work. Time to rethink your answers, they are useless and you are not an authority, quick acting like one.

On 5/25/18 4:02 PM, IntegratedDimensions wrote:
> 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; }

Parameters work the opposite way as return values. That is, you can't override a base class's function that accepts a base type with one that accepts a derived type. This is because you must be able to call the virtual function with the base type, and this would not work.

So what is technically possible is to call an overridden function with a base type (i.e. override a function that accepts a TT with one that accepts a T), but I don't know if D allows this, and obviously it doesn't help with your use case.

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

Hm... this is a runtime stack trace. And a crappy one at that (very little info at the top of the stack).

If you are getting this at compile time, then it's the compiler having an issue, which is automatically a bug (compiler should never throw an error).

If you have a reduced test case, I'd recommend filing an issue, and tagging it with ICE. But it needs to be reproducible.

-Steve