Discriminated [Union] extensibility

[StefanBertels]

Just checking https://github.com/louthy/language-ext/releases/tag/3.3.34.

Question 1: Should/could generated classes be partial or otherwise be more customizable? I read that you decided against this but sometimes could be nice to add e.g. attributes to generated classes or overwrite ToString() etc. I see that opening the classes might create new problems but maybe there are other ways to reduce problem surface like letting the code-generator check for existing properties (of possible) or require that the custom class has some [IKnowWhatImDoingHere] attribute.

Question 2: Could two union types be compatible like this?

    [Union]
    public interface ShapeWithCorners
    {
        ShapeWithCorners Rectangle(float width, float length);
        ShapeWithCorners Prism(float width, float height);
    }

    [Union]
    public interface EasyShape
    {
        EasyShape Rectangle(float width, float length);
        EasyShape Circle(float radius);
    }

At the moment this will result in conflicting code. But technically it should be possible for the generated classes to implement both interfaces.

[StefanBertels]

Related question: If you plan for [Record] code generation, then maybe allow building [Union] types based on [Record] types (which might open some options for extensibility). I don't have a specific syntax in mind, but some compatibility of union types, record types and perhaps custom things would be great. Maybe that means that generated [Record] types should be immutable (read only properties/fields and non-empty constructor).

[louthy]

My plan is to keep the case classes sealed, but to allow ad-hoc polymorphic behaviour via the class-instances system. So if you had a case called Circle then you could override ToString by defining ShowCircle, or if you want to override the equality behaviour then you could define EqCircle. PredCircle might also be used fir construction validation, but I’m not totally set on how that will work yet (maybe something that would work with Validation to provide useful error messages.

[StefanBertels]

Sounds good. Regarding ShowCircle: Could this be an option later for built-in data types, too? Like solving #593 by creating some ShowHashMapStringInt : Show<HashMap<string, int>>. Another idea: Could Show classes support IFormattable (format strings)?