template constraints when non-constrained template exists

[Manu via Digitalmars-d]

On 5 October 2015 at 18:26, Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Monday, 5 October 2015 at 08:14:14 UTC, Manu wrote:
>>
>> This comes up in many cases, I presume I've just missed something really
>> obvious...?

> So, you could certainly declare your own isUnsigned and similar traits, but
> they're not going to overload with the ones in std.traits and thus would
> likely have to fully qualified. I suspect that that thwarts what you're
> trying to do, but I think that it's pretty clear that these traits were
> _not_ intended to be true for any user-defined type.

Right, exactly. In most cases where this has come up for me, I'm
wrapping a built-in type in a thin skin to implement some specific
semantics.
In one case, I wanted a safer range limited integer with invariants to
prove the ranges. In my case today, I'm implementing a saturating
integer type (in the case of overflow it will clamp to min/max). These
are intended for injection into contexts where built-in's are
typically used, and they require interoperation with the standard
traits, otherwise I have to wrap all the standard traits needlessly
for every new type of this sort.

I've worked around this on many occasions, but it's always a bit
nasty, and in this case, it's particularly nasty because I'm
interacting with code I don't control.

Consider, if I were to submit a saturating integer to phobos, and then
submit PR's for support of the saturating int to std.traits, I'm
almost certain it would be rejected on account of adding unrelated
things to std.traits (if this, then why not the range limited int? Why
not fixed point? Why not Walter's half-float? These should all respond
appropriately to std.traits.

I think this problem needs a hygienic solution one way or another.


> 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.