On Monday, 5 October 2015 at 10:17:06 UTC, Manu wrote:
On 5 October 2015 at 18:26, Jonathan M Davis via Digitalmars-d
<[email protected]> wrote:
In general, the traits in std.traits are designed to match an
exact set of built-in types and that's it. And code using them
is going to rely on that, making overloading them very risky
IMHO.
I don't think it's risky, I think it should be expected. Surely
a type which has a concept of 'isSigned' should respond
accordingly to the standard introspection tools? It would be
the responsibility of the author of a fully-featured library to
make sure this works.
These traits were written and documented as only working with
built-in types. Changing that now could easily mean that existing
code would would then allow user-defined traits passed template
constraints on templates that will not work with user-defined
types - especially when you consider that these traits could be
combine with other traits to restrict what's accepted to a fairly
specific subset.
If these traits had be designed from the get-go with the idea
that they would work with any user-defined type that met certain
criteria, then that would be different, but they weren't.
Also, I think that a trait which _was_ supposed to work with
user-defined types would have to be very carefully written. This
very quickly gets into the camp where implicit conversions sit,
and those can be _really_ bad for template constraints, because
it's very easy to write a template constraint that accepts
implicit conversions and then end up with a template that works
with the target type but does not actually work with the types
that implicitly convert to it. They have their place, but you
have to be very careful with them.
It probably does make sense to declare some traits designed to
work with both the built-in types and user-defined types for some
of these arithmetic operations, but I expect that they would have
to be written very carefully to avoid problems, and I don't think
that it makes sense to change the existing traits to work that
way. I would be very surprised if such a change did not break
existing code.
- Jonathan M Davis
