On 5 October 2015 at 18:26, Jonathan M Davis via Digitalmars-d <[email protected]> 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.
