Make primitive integers always be Displayable and Debuggable.

[ltratt]

I have quite a lot of code which ends up looking like:

fn <F: PrimInt + Debug + Display>(v: F) {
  println!("{}", v};
}

AFAICS there isn't any fundamental need to force users to specify Debug and Display manually, since every primitive integer type implements those traits. This simple PR means that I can now happily do:

fn <F: PrimInt> (v: F) {
  println!("{}", v};
}

and get the same effect.

[ltratt]

The second commit is a hack to deal with the (I-should-have-seen-this-coming) fact that when compiled with no_std, Display and Debug aren't available. In the long run, I guess that trait aliases will be a nicer fix: we can use cfg to select the appropriate one depending on whether std/no_std is specified.

[cuviper]

It could import the traits from core for #[no_std] support, rather than toggling this entirely.

But unfortunately, adding constraints is a breaking change for external implementations of the trait. These do exist -- for instance extprim implements PrimInt for its 128-bit types. And while they do have Debug and Display already too, we can't know whether this is true for all existing implementations. There could be some internal newtype where someone didn't bother with display, for instance. (That would be a lot of work, but... it's possible.)

I suggest simply adding your own local trait combining these is the easier way forward.

[ltratt]

As a naive user, I naively expected that PrimInt would be debuggable and displayable. Not that naive users expectations are always a guide to good design though!

I agree that it's a breaking change. But I also agree with you that it probably won't break anything in practise, because I suspect neither of us can fathom the idea of a number you can't print out :) Perhaps on the next API bump it would not be unreasonable to add such constraints, perhaps Debug at a minimum?

That said, I understand your POV, and I won't be offended if you want to close the PR.

[cuviper]

I think with a semver bump, I'd be happy adding both. However, I have no plans to bump any time soon. Even the recent 0.2 bump came with no actual API changes, just feature changes to support #[no_std], and 0.1.43 reexporting it all to stay in sync.

Thanks for understanding!