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
