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.
