Extract some kind of RealNumber trait out of Float and make Float require it about num-traits HOT 4 CLOSED

It's definitely a breaking change for external implementors, as you mention. The new trait would have to stand alone. But I'd guess that's not so bad since implementors wouldn't have to do both, just the one most appropriate to them.

from num-traits.

I figure that the plan could be to add that new RealNum trait without touching Float, by copy-pasting appropriate items, then adding impl<T: Float> RealNum for T { /* trivial impls here */ } so that RealNum is useful to everyone right away.
Somewhere in there we'd leave a note saying "in the next major version increase, let's make Float require RealNum, and remove intersecting items." (or not - it's not mandatory)

I would be interested in doing a PR that does this, if you're OK with that. If not, it's fine too!
For now, people that really need it can make their fixed-point types implement Float's items, but use unimplemented!{} on those that are floating-point-specific - then, they only have to make sure these items are never used.
Alternatively, they can implement these items "incorrectly" but in a way that doesn't panic.

from num-traits.

So the problem is, that when splitting hierarchy, the implementors of Float will now additionaly have to implement RealNum, isn't it?
I don't think, anyone would implement Float, because it's only suited for floats like the built in types.
Maybe it's used for wrapper types.
Maybe it would be useful to be able to implement functions of supertraits in subtraits. This should then solve the current problem.
Is it worth thinking about an RFC for such a feature?

from num-traits.

So the problem is, that when splitting hierarchy, the implementors of Float will now additionaly have to implement RealNum, isn't it?
I don't think, anyone would implement Float, because it's only suited for floats like the built in types.
Maybe it's used for wrapper types.

Exactly -- for example, one such wrapper that I know of is NoisyFloat.

Maybe it would be useful to be able to implement functions of supertraits in subtraits. This should then solve the current problem.
Is it worth thinking about an RFC for such a feature?

You mean as a new language feature? I'm not sure if this is a frequent enough scenario to warrant that, but it doesn't hurt to propose the idea. Maybe start as a pre-RFC on the internals forum.

from num-traits.