Proposal: define signatures for generic type parameters

[ghost]

Regarding these two issues:
https://github.com/dotnet/corefx/issues/27167
#1233
I had a new suggestion to make more control of the generic type parameters:
In addition to constraints for generics, I suggest to allow us to define signatures for generic type parameters, such as:

generic Num: {byte, short, int, long}
{
     static Num Parse(string s);
     static Num operator + (Num x, Num y);
     static Num operator * (Num x, Num y);
     // …….
}

The above code tells the compiler that:
1- Num can only be one of the members mentioned in the type list: {byte, short, int, long}. Compiler must raise error for any other types.
2- Num has the Parse method, and can be used with the + and * operators, so compiler must allow codes like this:

var n = Num.Parse("10") ;
var n += n * n + 2;

This will be helpful when there is no suitable interface or base class to use as a constraint, which is the case of numeric types.

When Num is used as a type parameter, the compiler can use our provided signature to grantee that the code that seems late-pound is trusted in design time, and will work at run time. So, it is an early bound a like code, thanks to our generic signature.

So, the compiler can accept this:

class foo<Num>
{
    void DoSomething(Num a, Num b, Num c)
   { 
        // …..
        Num d = a + b * c + Num.Parse(textBox1.Text);
        // …..
    }
}

Benefits:
1- Not breaking any existing code.
2- No need for any change in CoreFX, but it requires additions to Roslyn and IL. There is no way to convert the generic signature to an interface, because interfaces doesn't accept static members, and also primitive numeric types doesn't overload arithmetic operators although they arte applied to them!
3- Has no impact on the runtime performance.
4- Generic signatures are reusable. so we can define as many signatures as we want for different cases, and put them in reusable modules.

Note:
Signature inheritance may be useful.. something like:

generic Num2: Num {sbyte, ushort, uint, ulong}
{
     static Num Parse(string s, IFormatProvider provider);
     static Num operator - (Num x, Num y);
     static Num operator / (Num x, Num y);
     // …….
}

Num2 combines its members list with that of Nums, and has all its members.

[CyrusNajmabadi]

How is this different/better than 'Shapes/Extensions': #164
?

Thanks!

[ghost]

@CyrusNajmabadi
At least signatures allow you to define Type list. It is meant for generic parameters, and the use is different. every time I look at shapes and extensions I feel they are difficult, or need more effort to comprehend. It's welcomed If the two ideas can be combined.
Thanks.

[CyrusNajmabadi]

Can you explain what this means:

// so compiler must allow codes like this:

var n = Num.Parse("10") ;
var n += n * n + 2;

how would that work? + on two ints is very different from + on two longs.

[ghost]

I already did:

When Num is used as a type parameter, the compiler can use our provided signature to grantee that the code that seems late-pound is trusted in design time, and will work at run time. So, it is an early bound a like code, thanks to our generic signature.

in design time, the compiler just lit is pass. In runtime,if Num is int it will be:

var n = int.Parse("10") ;
var n += n * n + 2;

So, no more action is needed.

[CyrusNajmabadi]

Sorry, i don't get how this would actually work. What code would actually get generated here. How would it make sure that the right operators were actually called at runtime?

[ghost]

If you are confused because I used + 2 in the example, maybe you are right. If I did this and the compiler complains about the conversion from 2 to Num, I would modify the Num signature to add a conversion operator from int To Num, or a + operator that accepts Num and int.
But, I may go further and say this:
With some reflection, we can eliminate the need for the signature methods and let the compilre check the type list. If it found that all types have the needed method or operators, then the code is safe to run, otherwise it raises an error.
I can't tell which approach is better and easy to implement.

[CyrusNajmabadi]

I would modify the Num signature to add a conversion operator from int To Num, or a + operator that accepts Num and int.

Could you explain then how this is different from you just creating a Num struct and adding those operators to it yourself? In other words, it sounds like you can already do this today. So why would we need to change the language here?

[ghost]

Or use double for all numeric operations!
But the cost is high, and this is why c# added generics, to use the exact type that data fits in.
These comments amy answer your question:
https://github.com/dotnet/corefx/issues/27167#issuecomment-373442304
https://github.com/dotnet/corefx/issues/27167#issuecomment-373780009
https://github.com/dotnet/corefx/issues/27167#issuecomment-373797248
Thanks.

[CyrusNajmabadi]

I don't understand your proposal. You say you just want to have implicit conversions to Num so you can have these operators defined in one place. But you can already have that today. You then say:

But the cost is high,

But haven't explained how your proposal makes the cost low. How does your proposal actually work. For example, can you explain the IL that hte compiler would generate when it encounters these constructs? I'm trying to figure out what it would actually get compiled down to and how it would ensure that "But the cost is high" would not be true. Thanks!

[ghost]

Is it regualar to ask a C# programmer about IL code? This is not my area. I only make a suggestion from a programmer's point of view, and you tell me if it is doable or not. This is why we discuss.
Thanks.

[CyrusNajmabadi]

I only make a suggestion from a programmer's point of view, and you tell me if it is doable or not.

It's your proposal, it's important to at least be able to explain certain parts of it. Right now i'm not seeing how you would do this. As such, i need more information from you here.

[ghost]

True. But it is also a teamwork in an open source community, so, I welcome any addition or correction.

[CyrusNajmabadi]

I welcome any addition or correction.

Given how you've described things so far (especially your bit about: "I would modify the Num signature to add a conversion operator from int To Num, or a + operator that accepts Num and int.") then i would just do this today in C# using a "struct Num" with implicit conversions in it. It doesn't seem like you need a new language feature.

[ghost]

Please read the links I mentioned before. This issue is marked as a future work in CoreFx, because this is a problem in other areas like tensor

[CyrusNajmabadi]

I read the links. You still haven't addressed how this would work. Also, my comment about having a "struct Num" said nothing about using an 'object' as the internal representation.

One of the linked post also said this:

I think the current C# proposal for type classes/shapes has much more promise. It has the potential to work with purely compiler features, though we might add some default implementations of the shapes/concepts/whatever-they-get-named in the framework itself to facilitate ease of use and type exchange.

I'd highly recommend you look through the type class / shapes issues in CSharpLang. I believe those are good generalizations of this type of problem and have the best chance at getting a solution that can reach to the largest number of C# developers.

I agree with this advice. Shapes/Extensions has a rich proposal behind it, handles a superset of the use cases that you seem to care about, and actually provides a way that explains how this would generate code.

[rossdempster]

The idea is just to guarantee that T supports a certain set of operations, right? Perhaps the intent is more obvious this way? (and more inline with existing syntax)

constraint Num: byte, short, int, long
{
     static Num Parse(string s);
     static Num operator + (Num x, Num y);
     static Num operator * (Num x, Num y);
     // …….
}

class NumList<T>
    where T : Num       // <- here is where we declare what T must be capable of
{
    public void AddFromText(string text) => _inner.Add(T.Parse(text));
    public T Sum() => _inner.Aggregate((acc, v) => acc + v);
}

Elsewhere:

var list = new NumList<int>();
list.AddFromText("15");
list.AddFromText("17");
var sum = list.Sum();

@MohammadHamdyGhanem. I think what Cyrus is saying is that we must generate one shared piece of IL for class NumList (or foo in your example), and that's not trivial (or even possible, perhaps) because the function calls would be different depending on what actual T you used (byte, int etc.).

@CyrusNajmabadi. To answer the question of "what code would actually get generated?". I think the constraint Num could potentially generate a generic interface with the various required methods, and then generate an implementation of that interface for each of the supported base types (basically thunks to the real methods). NumList would generate code bound against the interface (presumably instanced in the constructor according to T, and stored in a hidden field).

I'm sure this would be a lot more useful if the constraint was open though, i.e. you don't say what the valid types are, rather it just uses "duck typing" to match the various methods. In that case it's not as clear who would generate the thunks. And reflection based construction through MakeGenericType() is even more of a mystery.

[ghost]

I faced a situation where I need to define a method accepts a char or Escapes as a parameter, where Escapes is defined as this:

    public struct Escapes
    {
        public readonly string Value;
        private Escapes(string value) => Value = value;
        public static implicit operator string(Escapes r) => r.Value;
        public override string ToString() => Value;

        public static readonly Escapes LineFeed = new Escapes(@"\n");
        public static readonly Escapes CarriageReturn = new Escapes(new Escapes(@"\r"));
        public static readonly Escapes Digit = new Escapes(@"\d");
       // ........................
    }

I solved this by defining this class:

    public class CharOrEscape
    {
        public string Value;
        public static implicit operator CharOrEscape(Escapes s) => new CharOrEscape(s);
        public static implicit operator CharOrEscape(char c) => new CharOrEscape(c.ToString());
        public override string ToString() => Value;
        private CharOrEscape(string value) => Value = value;
    }

Now, it is possible to use CharOrEscape as a parameter, and treat it in code as string:

        public Verex AppendToRange(params CharOrEscape[] values)
        {
        }

So, I can use this method like this:

var ValidChars = Verex.New.EnglishAlphabetOrHyphenOrDigit.AppendToRange('.', Escapes.Minus);
This makes sure that the input is one char or a 2-char string that starts with \ .