Clarify support of inherited attributes in v3

[pkindruk]

As a library user you can inherit MessagePack attributes. In 2.5.172 it works and can be used for something, because reflection finds child attribute types and runs attribute constructors. Analyzer for 2.5.172 is not allowing this, but you are not forced to use it.
From my understanding of source generators this behavior can't be implemented as you would need to compile and execute user code inside compilation.

I think this should be included in migration guide for v3.

Sample code.

public static class MessagePackTest4
{
    public static void Run()
    {
        var obj1 = new B { Prop1 = "t1", Prop2 = "t11", Prop3 = "t111", Prop4 = "t1111" };
        var data = MessagePackSerializer.Serialize(obj1);
        var obj2 = MessagePackSerializer.Deserialize<B>(data);

        // Outputs: {"A1":"t1","A2":"t11","B1":"t111","B2":"t1111"}
        Console.WriteLine(MessagePackSerializer.ConvertToJson(data));
    }

    [MessagePackObject]
    public class A
    {
        [CompositeKey(0, 1)]
        public string Prop1 { get; set; }

        [CompositeKey(0, 2)]
        public string Prop2 { get; set; }
    }

    [MessagePackObject]
    public class B : A
    {
        [CompositeKey(1, 1)]
        public string Prop3 { get; set; }

        [CompositeKey(1, 2)]
        public string Prop4 { get; set; }
    }

    public class CompositeKeyAttribute : KeyAttribute
    {
        public CompositeKeyAttribute(byte level, int index)
            : base(CreateKey(level, index)) { }

        public static string CreateKey(byte level, int index)
        {
            var c = (char)('A' + level);
            return c + index.ToString("x");
        }
    }
}

[AArnott]

Interesting use case. You are correct, and yes at minimum we can add this mention to the migration guide.

[pkindruk]

Not something I use. This just an idea that my colleague proposed when we were discussing how to deal with inheritance.
Also it might be tempting to inherit from MessagePackObjectAttribute and redefine defaults.

[AArnott]

Also it might be tempting to inherit from MessagePackObjectAttribute and redefine defaults.

Such ideas are fairly straightforward when using reflection at runtime to get the attribute values. But when using source generators, which is the way we're going in v3, it doesn't work. You'd have to write your own source generator to interpret your attribute.

[AArnott]

In fact we probably should have sealed the attributes so they cannot be overridden. Maybe we should in v3, though it would be a breaking change (to the few there may be that do it).