Bug in D!!!

[EntangledQuanta via Digitalmars-d-learn]

On Wednesday, 30 August 2017 at 22:08:03 UTC, Jonathan M Davis 
wrote:
> On Wednesday, August 30, 2017 21:51:57 EntangledQuanta via 
> Digitalmars-d- learn wrote:
>> The point you are trying to making, and not doing a great job, 
>> is that the compiler cannot create an unknown set of virtual 
>> functions from a single templated virtual function. BUT, when 
>> you realize that is what the problem is, the unknown set is 
>> the issue NOT templated virtual functions. Make the set known 
>> and finite somehow then you have a solution, and it's not that 
>> difficult. Just requires some elbow grease.
>
> Templates have no idea what arguments you intend to use with 
> them. You can pass them any arguments you want, and as long as 
> they pass the template constraint, the compiler will attempt to 
> instiate the template with those arguments - which may or may 
> not compile, but the compiler doesn't care about that until you 
> attempt to instantiate the template.
>
> The language does not support a mechanism for creating a 
> templated function where you define ahead of time what all of 
> the legal arguments are such that the compiler will just 
> instantiate them all for you. The compiler only instantiates 
> templates when the code instantiates them. Feel free to open up 
> an enhancement request for some sort of template which has a 
> specified list of arguments to be instantiated with which the 
> compiler will then instantiate up front and allow no others, 
> but that is not currently a language feature.

and my point is that it is not always the case that T can be 
anything. What if T is meant to only be algebraic?

auto foo(T : Algebraic!(int, float, double))(T t){ }

will the compiler be smart enough to be able to deduce that there 
are only 3 possibilities? No, but it should. (but of course, we 
don't want to use algebraic because that makes thing messy, and 
the whole point of all this is to reduce the mess)

As far as a feature request, my guess is no one will care, I'd 
hope that wouldn't be the case, but seeming how much excitement 
in solving this problem has generated leads me to believe no one 
really cares about solving it.

> The normal solution for something like that right now would be 
> to explicitly declare each function that you want and then have 
> them call a templated function in order to share the 
> implementation. e.g.
>
> class C
> {
> public:
>
>     auto foo(int i) { return _foo(i); }
>     auto foo(float f) { return _foo(f); }
>     auto foo(string s) { return _foo(s); }
>
> private:
>
>     auto _foo(T)(T T) { ...}
> }
>
> - Jonathan M Davis

Yes, but this is really just explicit overloading. It doesn't 
solve the problem that templates are suppose to solve. When one 
starts overloading things, it becomes a bigger mess as each class 
needs to deal with the overloading and dispatching. It all could 
be solved with a bit of compiler "magic"(which should be quite 
simple).

I mean, the compiler optimizes all kinds of things, this case 
shouldn't be any different. If it can determine a template 
parameter is reasonably finite then it should convert the 
templates method in to a series of overloaded methods for us... 
which is what you essentially did.