Proposal: syntactic sugar - closed generic type

[ghostnguyen]

Instead of declare specific class name for closed generic type,

class P1 : ProductPrice<Silver, DailyCare> 

developers can declare like this:

partial class this : ProductPrice<Silver, DailyCare>

At using, developers don't have to write down the specific class name.
At compiling time, compiler will generate class name and subtitle using as normal for closed generic type.

class Program
    {
        static void Main(string[] args)
        {
            var list = new IDiscount[] {
                new ProductPrice<Standard, DailyCare>(),
                new ProductPrice<Silver, DailyCare>(),
                new ProductPrice<Standard, Luxury>()
            };

            foreach (var item in list)
            {
                item.GetRate();
            }

            //Expect 1
            //Expect 0.9
            //Expect 0.5
        }
    }

    partial class this : ProductPrice<Silver, DailyCare>
    {
        public decimal GetRate()
        {
            return 0.9;
        }
    }

    partial class this : ProductPrice<Standard, Luxury>
    {
        public decimal GetRate()
        {
            return 0.5;
        }
    }

    class ProductPrice<T1, T2> : IDiscount
            where T1 : CustomerType
            where T2 : ProductType
        {
            public decimal GetRate()
            {
                return 1;
            }
        }
        interface IDiscount
        {
            decimal GetRate();
        }

        abstract class ProductType { }

        class DailyCare : ProductType { }

        class Luxury : ProductType { }


        abstract class CustomerType { }

        class Standard : CustomerType { }

        class Silver : CustomerType { }
    

[ufcpp]

you mean Generic Specialization?

[ghostnguyen]

It seems to solve the same problem.

[bondsbw]

I like the concept.

I'm not easy about using this. I think I prefer the other proposal's syntax, where your example would change to:

class ProductPrice<T1, T2> : IDiscount
    where T1 : CustomerType
    where T2 : ProductType
{
    public virtual decimal GetRate() => 1m;
}

// later...

class ProductPrice<Silver, DailyCare>
{
    public override decimal GetRate() => 0.9m;
}

Also note how I added virtual and override since this new syntax is just sugar for declaring an inherited type. For the same reason, there is no need for the partial class modifier.

[ghostnguyen]

Just thought if we use this directly,

class ProductPrice<Silver, DailyCare>
{
    public override decimal GetRate() => 0.9m;
}

Which current behavior, complier will consider <Silver, DailyCare> are another type parameters in another generic class which is duplicated.

There maybe a better way than 'this' keyword, anyway we should not change the existing behavior of compiler.

[bondsbw]

I don't think that's a problem since it requires the generic version and the specialized version to be declared with the same name in the same namespace (which is currently an error).

But there is still an issue with that, it may not be possible in some situations to figure out which one is the generic and which is the specialized. The proposal in #1315 is ok there because the specialized version uses built-in types like int, which are not allowed as type parameters. But other type names are allowed as type parameters, so there would be an ambiguity.

As mentioned in the other issue, the shapes proposal is probably capable of fulfilling this need.

[ghostnguyen]

I agree with you that the proposal in #1315 introduces a specialized class which would lead to ambiguity and may difficulty to implementing than a simple syntactic sugar.

About shape #164, it seem to over complicated to me, and the return benefit is not difference in my situation, if not at all.