Amadeusz Sadowski

Partially covered by #55. Consider other attributes especially on methods.

Noting down for future: Let's start with the easiest scenario: closed hierarchy. So all base classes are abstract, and all leaf classes (non-abstract) are sealed. This gives us full knowledge...

A good reference point with a working implementation: https://github.com/WarHub/wham/blob/af6b15ec1ee8c988e59b4f4223e3bb8673d8a06d/src/WarHub.ArmouryModel.Source.CodeGeneration/Generators/RecordCorePartialGenerator.cs

Constructor is easy: parameter list is base.Properties.Concat(this.Properties), and pass base.Properties to `base(…)` call. ~~Builder is simply not included in abstract records, since they can't be instantiated. One *could* think about...

With that in mind, a design for the inheritance records could be written as follows. We need to know the following about a given record: * is it abstract /...

@bboyle1234 ```csharp BaseClass @base = new NextClass("a", "b"); var baseBuilder = @base.ToBuilder(); ``` The `ToBuilder` method will have to be `new`ed as well because the return type changes, and as...

In your scenario, why would this not be enough? ```csharp public interface IEvent { Guid Id { get; } TimeStamp At { get; } } [Record] public abstract partial class...

> why not autogen the interface properties Well, I'd really like to keep requiring all the properties being user-defined. I could imagine generating an interface *from* a record, like ```csharp...

It is a nice optimization I've been thinking about at some point as well. I think it should be the new behavior (non-optional). I can't imagine a case where one...

I'm glad you built this so quickly and easily, working simple code is the best code. However: * Any new Feature should be first hidden behind a new `Features` flag....