Generic Math Interfaces and Container Issues

[HellGate94]

Generic math is a great step forwards the way it is done with interfaces comes with some issues especially when creating containers like Vector2<T> for example that should inherit functionality from the underlying type. If you, for example, create 3 instances like: Vector2<bool>, Vector2<int> and Vector2<float>. There is no way Vector2<T> can support all those example types (with support I mean provide all operators that the base type has, as per component operators) at the same time because implementing interfaces for one type will lock out the others.

The only way I can currently think of that would allow this to work would require 2 other features to be implemented first. First one being additional type restrictions on methods similar to how extension methods allow it eg: public static Vector2<T> operator *(Vector2<T> left, Vector2<T> right) where T : IMultiplyOperators<T, T, T> in combination with something like shapes that allow for targeting some of the generic implementations that end up satisfying all constraints.

It would be great if there was a way to support this behavior in some way. Also I feel like the current approach could potentially create issues in the future when adding support for something like this

[YairHalberstadt]

Extensions might be able to solve this #5497

E.g.

extension AddableVector<T> for Vector<T> : IAddable<AddableVector<T>> where T : IAddable<T>
{
    // Impl goes here
}

[HellGate94]

If extensions can add operators then it could potentially solve this issue from what I can see.

[MadsTorgersen]

This is indeed an intended scenario for extensions.

[djblack]

In practice, the examples given work fine if some conventions are adopted. For example bool maps to 0/1 or integers behave like floats which are truncated/rounded.

Are there examples where this causes bigger problems?

[HellGate94]

Not sure if you want to just use floats and then reinterpret them or suggesting that all types should basically implement all operators. Either way I don't think that's a good argument. Sooner or later there is going to be something that one type supports but another doesn't then this problem appears again. The container itself does not (want to) have any type constraints it just offers additional functionality that requires the current interfaces to work

[djblack]

I guess it depends what interfaces the base types choose to implement...
An ugly alternative would be a wrapper struct, eg a NumericBool type (which performs modular/saturating arithmetic, with n=2).