template constraints when non-constrained template exists

[Jonathan M Davis via Digitalmars-d]

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 
> <digitalmars-d at puremagic.com> 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