Request for a more powerful template specialization feature

[data pulverizer via Digitalmars-d]

On Friday, 14 July 2017 at 18:19:03 UTC, data pulverizer wrote:
> Dear all,
>
> Template specializations are a great feature in D. They allow 
> the programmer to create template specializations but they can 
> also be a powerful way of constraining templates by 
> implementing only the specializations that you need. In 
> contrast template constraints can quickly become very complex 
> for the programmer to write and reason about.
>
> Template specializations should be extended to allow multiple 
> lists of types to be implemented together. For example this ...
>
> template Construct(R: Union{double, int}, W: Union{string, 
> char, dchar})
> {
>     auto Construct(R, W)(R r, W w)
>     {
>         ....
>     }
> }
>
> The same definition would be allowed for all 6 combinations of 
> {double, int} and {string, char, dchar} (and no more! Unless 
> specified otherwise and/or more generally). This would remove 
> the need to manually write these for all combinations or resort 
> to constraints.
>
> In addition for some use cases it is a nicer way of doing 
> unions than using the current union keyword. Union{double, int} 
> could be a compile-time construct indicating that the type can 
> be either an actual double or int. It can replace the use of 
> union in cases where you want a substitution of either double 
> or int for this Union rather than a union type. In addition, 
> variants return variants rather than "properly" typed data.
>
> It would be good to get comments and suggestions before I write 
> a DIP.
>
> Thank you in advance.

I am aware that this suggestion touches the language and the 
compiler - and may significant implications. I would like to know 
whether this could be done without too much effort and whether it 
would break anything else?

If you are writing lots of overloaded templates, constraints can 
have unintended behaviour because you end up telling the compiler 
what not to do rather than what to do. The above Unions are clear 
and simple, easy to use and should result in cleaner more robust 
code.