Bug in D!!!

[Moritz Maxeiner via Digitalmars-d-learn]

On Saturday, 2 September 2017 at 00:00:43 UTC, EntangledQuanta 
wrote:
> On Friday, 1 September 2017 at 23:25:04 UTC, Jesse Phillips 
> wrote:
>> I've love being able to inherit and override generic functions 
>> in C#. Unfortunately C# doesn't use templates and I hit so 
>> many other issues where Generics just suck.
>>
>> I don't think it is appropriate to dismiss the need for the 
>> compiler to generate a virtual function for every instantiated 
>> T, after all, the compiler can't know you have a finite known 
>> set of T unless you tell it.
>>
>> But lets assume we've told the compiler that it is compiling 
>> all the source code and it does not need to compile for future 
>> linking.
>>
>> First the compiler will need to make sure all virtual 
>> functions can be generated for the derived classes. In this 
>> case the compiler must note the template function and validate 
>> all derived classes include it. That was easy.
>>
>> Next up each instantiation of the function needs a new v-table 
>> entry in all derived classes. Current compiler implementation 
>> will compile each module independently of each other; so this 
>> feature could be specified to work within the same module or 
>> new semantics can be written up of how the compiler modifies 
>> already compiled modules and those which reference the 
>> compiled modules (the object sizes would be changing due to 
>> the v-table modifications)
>>
>> With those three simple changes to the language I think that 
>> this feature will work for every T.
>
> Specifying that there will be no further linkage is the same as 
> making T finite. T must be finite.
>
> C# uses generics/IR/CLR so it can do things at run time that is 
> effectively compile time for D.
>
> By simply extending the grammar slightly in an intuitive way, 
> we can get the explicit finite case, which is easy:
>
> foo(T in [A,B,C])()
>
> and possibly for your case
>
> foo(T in <module>)() would work
>
> or
>
> foo(T in <program>)()
>
> the `in` keyword makes sense here and is not used nor 
> ambiguous, I believe.

While I agree that `in` does make sense for the semantics 
involved, it is already used to do a failable key lookup (return 
pointer to value or null if not present) into an associative 
array [1] and input contracts. It wouldn't be ambiguous AFAICT, 
but having a keyword mean three different things depending on 
context would make the language even more complex (to read).

W.r.t. to the idea in general: I think something like that could 
be valuable to have in the language, but since this essentially 
amounts to syntactic sugar (AFAICT), but I'm not (yet) convinced 
that with `static foreach` being included it's worth the cost.

[1] https://dlang.org/spec/expression.html#InExpression