Add interfaces for primitives

[JustNrik]

My suggestion is to add the following interfaces

public interface IPrimitive { }
public interface INumeric : IPrimitive { }
public interface INonNumeric : IPrimitive { } // used for Char, String, DateTime, DateTimeOffset and TimeSpan
public interface IInteger : INumeric { } // used for Byte, Int16/32/64 and possibly BigInteger
public interface IReal : INumeric { } // used for Single, Double and Decimal
public interface IComplex : INumeric { } // used for complex numbers maybe?

Although they don't have any member to implement (pretty much "cosmetic" interfaces) they would be useful for generic constrains. For example:

public struct Vector<TX, TY> 
    where X : IReal 
    where Y : IReal
{
    public TX X { get; set; }
    public TY Y { get; set; }

    public Vector(TX x, TY y)
    {
        X = x;
        Y = y;
    }
}

So we could use it as:

var vector = new Vector<float, float>(5.0f, 2.5f);

instead of creating 3 different structs with pretty much the same logic

What do you think guys?

[svick]

If those interfaces don't have any members, how are you going to implement that logic? Say, you wanted to be able to add two Vectors together. How do you implement that?

If you mean that this would be only for types that don't have any members that operate with the Ts, then what would be the point of those constraints?

[scalablecory]

A better idea of a "static interface" has been floated in the past, which would allow defining static methods and operators. Not sure where that is, there's probably an issue for it still.

[chucker]

A better idea of a "static interface" has been floated in the past, which would allow defining static methods and operators. Not sure where that is, there's probably an issue for it still.

You might be thinking of Shapes, which sounds like what OP is suggesting here.

[jnm2]

@chucker I think #1711 supersedes that issue.

[JustNrik]

If those interfaces don't have any members, how are you going to implement that logic? Say, you wanted to be able to add two Vectors together. How do you implement that?

If you mean that this would be only for types that don't have any members that operate with the Ts, then what would be the point of those constraints?

What I meant is, to have a common interfaces between primitive types, just as an example, let's take vectors. Why should I make a so many vector structs when I could have a generic one? which currently ins't possible unless you make conversions and a load of methods, for example, a simple Vector<int, int> has its logic, but there could be a bigger vector, like Vector<long, long>, they both will have exactly the same logic, the only difference is that Vector<int, int> properties will be both int and Vector<long, long> properties will be long, this would also be useful for methods that involve working with numbers, for example, you could have a method to do math operations with whole numbers instead of creating an overload with the same logic for int, long, etc... They could have members as well I just don't know which ones all primitives have, one could be MaxValue and MinValue but that would require the interface to accept static/const members, which is possible since as far as I know, CRL allows constants on interfaces but they aren't allowed on .NET langs by design, so these interfaces would end up being like this:

public interface INumeric<T> where T : INumeric
{
    const T MaxValue;
    const T MinValue;
}

Another possibility would be to make INumeric<T> to inherit all interfaces numeric primitives implement, like IComparable<T>, IEquatable<T>, etc... So the interface won't be there just empty being a make up

A better idea of a "static interface" has been floated in the past, which would allow defining static methods and operators. Not sure where that is, there's probably an issue for it still.

You might be thinking of Shapes, which sounds like what OP is suggesting here.

Not exactly but my suggestion is related to it somehow, the idea of Shapes is really interesting

In general, my suggestion would look kind of like this (assuming the possibility of static/const members on interfaces):

public interface IPrimitive : IComparable, IConvertible, IFormattable, ISpanFormattable { }
public interface IPrimitive<T> : IPrimitive, IComparable<T>, IEquatable<T>
{
    static T Parse(string s);
    static T Parse(string s, IFormatProvider provider);
    static bool TryParse(string s, out T result);
    static bool TryParse(string s, IFormatProvider provider, out T result);
}
public interface INumeric : IPrimitive { }
public interface INumeric<T> where T : INumeric
{
    const T MinValue;
    const T MaxValue;
    static T Parse(string s, NumberStyle numberStyle);
    static bool TryParse(string s, NumberStyle numberStyle, out T result);
}

you may get an idea from here I guess

[theunrepentantgeek]

Writing an algorithm dependent on vectoring everything through INumeric (or any interface) would perform really really badly:

• Every value would end up boxed, on the heap
• Every call would have to go through virtual method dispatch
• Plus, regular operators (like + * etc) would be unavailable

Something like the Shapes proposal (#164) will be better performant.

[YairHalberstadt]

@theunrepentantgeek

Not if the interface was used as a generic constraint. Then every instance of the generic type would get specialised, as the numeric primitives are all value types.

The performance is equavilent to that produced by CodeGen.

[GalaxiaGuy]

Interestingly, something like this must have been seriously investigated at some point:

https://github.com/Microsoft/referencesource/search?q=iarithmetic&unscoped_q=iarithmetic

[john-h-k]

Personally I would just want this as a generic constraint. E.g, void Meth<T>() where T : primitive

[JustNrik]

Personally I would just want this as a generic constraint. E.g, void Meth<T>() where T : primitive

That'd work too, but here should be more constrains, like for numeric and non-numeric (date and string/char)

[john-h-k]

Neither DateTime nor String is primitive

[JustNrik]

Neither DateTime nor String is primitive

Oh I see, decimal isn't a primitive either so I guess numeric constrain would be better?

[john-h-k]

I guess, though a primitive constraint might still have uses

[jnm2]

@johnkellyoxford

void Meth

What now? :D

[HaloFour]

(assuming the possibility of static/const members on interfaces)

Neither static nor const members make sense on interfaces. The former requires an instance through which to perform a vtable lookup in order to implement a virtual dispatch. The latter is not a proper member and requires that the compiler resolve and replace with the actual value at compile time.

I'd think all of the functionality that you're looking for can be accomplished through shapes, which will be significantly more flexible and performant than normal interfaces could be in these circumstances.

[chucker]

You might be thinking of Shapes, which sounds like what OP is suggesting here.

Not exactly but my suggestion is related to it somehow, the idea of Shapes is really interesting

In general, my suggestion would look kind of like this (assuming the possibility of static/const members on interfaces):

[..] static bool TryParse(string s, IFormatProvider provider, out T result);

you may get an idea from here I guess

I feel like this is quite close to the Shapes and Extensions proposal:

• you want to retroactively add a contract* to existing types such as System.Int32. Interfaces currently only work if predefined in the type. Short of writing your own implementation of int, it's not currently possible to add any further contract.
• you want that contract to have static members. Interfaces only support instance members.

Both of these are precisely the example given by Mads: first, he defines a contract public shape SGroup<T>, using a shape. Then, he implements this for int using an extension: public extension IntGroup of int : SGroup<int>. So now we're retroactively implementing code that works on int. And that contract has static members.

From my understanding, in a world where int.TryParse, double.TryParse and so forth didn't already exist and Shapes and Extensions did, they would instead be declared inside an SParseable<T>.

Since you said "not exactly" — semantics aside, is there something in particular about your proposal that differs?

*) I'm avoiding the word interface or shape in favor of something more all-encompassing.

[JustNrik]

You might be thinking of Shapes, which sounds like what OP is suggesting here.

Not exactly but my suggestion is related to it somehow, the idea of Shapes is really interesting
In general, my suggestion would look kind of like this (assuming the possibility of static/const members on interfaces):
[..] static bool TryParse(string s, IFormatProvider provider, out T result);
you may get an idea from here I guess

I feel like this is quite close to the Shapes and Extensions proposal:

* you want to retroactively add a contract* to _existing_ types such as `System.Int32`. Interfaces currently only work if predefined in the type. Short of writing your own implementation of `int`, it's not currently possible to add any further contract.

* you want that contract to have static members. Interfaces only support instance members.

Both of these are precisely the example given by Mads: first, he defines a contract public shape SGroup<T>, using a shape. Then, he implements this for int using an extension: public extension IntGroup of int : SGroup<int>. So now we're retroactively implementing code that works on int. And that contract has static members.

From my understanding, in a world where int.TryParse, double.TryParse and so forth didn't already exist and Shapes and Extensions did, they would instead be declared inside an SParseable<T>.

Since you said "not exactly" — semantics aside, is there something in particular about your proposal that differs?

*) I'm avoiding the word interface or shape in favor of something more all-encompassing.

I was thinking in smth like this: https://sharplab.io/#v2:EYLgHgbALANALiAhgZwLYB8ACAGABJgRgG4BYAKB1wGUALRAJwAcAZRYAOgCUBXAOzgCWqAKaky5ANoApAXADiw3sPoCAxgAo4AT0bCA9gDN1A/gEpTMXDPmLlazTv1GANnt4Bzc5esKlKjdq6hupy3AIAJuYAuuSYAMz4BBD4AEy4AIIqcDQigqoAPAAqAHy4AO40ysK4hbgguMhw9NyqcOQA3uS43fgJhMm1VNzATYit6rXOwgZwlrUq7jRwpl09nWQ9m7gCBrgOQUaFprgAvCe4gU7GZisbW93r990AkJgA7HtH6nrAAFbCrVM6muy2+fwByymM1wAFo9iZQT9/oCFktTGInrgAL6re7CZzIao7PaXYJHU7nUkuNyeW6Yx6YnrvT5ApEQoHqVweVngwFQuCwvZczxg5HLVHLDFPHF3PEE4S4rYMxm4AD0quoND03Gc4Vw4WmiB1AuAYwA1hc9A1XGVcIxENlLMgWjRcCh8Hh6NMpq0BG5FZj1ZbcKpKqoLQY9PRcHpGAB9IYjehjAWIXh61SIZzOEzuC50NqyxnZeh6W1KW0AOT0cAAkqhGFMRPxhOEAKJgVTCRiCNzqdEBnoyzYyrFAA

Although, I haven't benchmarked to see if it is poor performant as people claims.

[john-h-k]

@JustNrik while that looks horrifying in C#, it's clearly very well optimised by the JIT to remove all the casts, so I wouldn't think it was poor performing

[HaloFour]

@JustNrik

I'm not sure what that static class example has to do with your proposal.

The shapes proposals handle specialization in a different way, through witness structs that implement the shape "interface". The witness structs would be automatically generated by the compiler and would wire up the instance and static members of the target instance to the members of the shape:

https://sharplab.io/#v2:EYLgHgbALANALiAhgZwLYB8ACAGABJgRgG4BYAKHMwGZcBLAOzgFMAnAM0QGMncBJAQRa04AC1RM4tTgB4AKgD5cAb3K41uWbn4ATbQApNAe1GsAlKTLqNuAMoBXYHBZc4B3MZFmLAX3KUayE52nHB8jILCYhJSuCB8EaLikjIMcIoqluoADkIAbojMuCxMiNqG9AA2AJ50jLj5FXZMFlaq6tRhcAlRyXqp9YiNTKbKbVZqorTIAHQNTbgAvANDLeq+mWpj+DT9Ovr9HmajG+OYAOzL8wDU7iYsq2rrrScd/faOziF9dYcsIxnjdoXOY8AC0t089y263W/lwgRYwVCABlygBzbpJGJxARCRLRGQVdHpLY5Wj5QrFUrlaq4In0NGXZpbLYdVEMzEEvT0xkg/5bKyTGYgxZMh64J7qVk0HlaXTc9EQo4AwH4YGDa5KqEnSWbF4yxXvJwuBUMrX8k5Wc5M3Dg37imFAA===

This example might be more inline with the original shapes proposal:

https://sharplab.io/#v2:EYLgHgbALANALiAhgZwLYB8ACAGABJgRgG4BYAKB1wGUALRAJwAcAZRYAOgCUBXAOzgCWqAKaky5APQAqcpgDMuZHUbDqAQXoC4NEYIDGAHgAqAPlwBvcrmv4CEXEdwB7FfURwn9XAGoAFI7AYB1wATwBKMRtbe0cXYTcPLwBaf1xA4PDIm0J7YCcnABsHehCABQZkYV9CPAFeRm44IKdG4IA3RALuYQirbLtggC14pwtcAHNhOCJcAF9yebIpCXJZBTq4eIAzRD1VAEkNLR0pgUNTCz7rWMYAfTUAEwetASdeVPTHTKvgl1uqbjAOBuPSCN4fIJfXpkKJ5QrFMoVKo1XB1BpNZytRwdLo9LLXXDDeijcwTKYzRaLNaKYHcUG4fb8I7aXRnXAgBnMk76AwbMyWGE2H7yVH8Zx3R7PMHvDZpIKy8KXQVRayYADsaR8oXxcx+wvWYr+AKBIOlvll6QVYSVKuyGrAuCS2p+iyi+twcKKRhK5XolWqBFq9UazVaspx3WtAttqo1G3Y3sRfqqaJDmLguAjeJdeuV+ANGaJowAvGZsGIqRQFMhafTmG9xlzWXp2ZzNCzToYCg3+bmoiLu7xxuL7k8XuDB8P0pPQlGfv37VqQjrXUK8wOGyPjcDdmaZ9PN4rozH1Zqncuc3n3Z6Eb7/SjUxiWhmZ1m53mF7hJwmfUjzcGn1aN8Vz7bIFBnItcFLXBsGYCtVirfAACZcAAYRtNcomkd1HDvYQ1F4B5JWMEwAyDdFIWcbR4mtAB3Gh4lURwOSoJtOww20BC2XB/B/JN/UfUMMw6Lw33fGMVVPLMtScaj6B1KJV1tU8jHYIsQLzZZQOsABtAApLQAHFhF4eIzl8OAQhUJwtn/OAwiCSzrNsxk4DY/QwjCABdH59KMkyzL0CyrOEGzfEnBzcCc0LbPrId3LOTyfPXBRcKRAiiKeYwgn2VBGAKUiHwAyjZIY+g6LKg48qKDka3oOkMUOdtuTOEiOJVecbC4niHmEHZuAKOBfFy/Kwj4vD/wo9N2k6SNxIku1cF6/rBuG6qxr+SVx3eLNmjk6EJKUySNWWxABqGkaCjG9TL1mIA==

Of course the design of shapes/roles/extensions/etc is very up in the air, but of the motivations seems to be making this kind of programming possible and efficient.