Make common members accessible without matching about dunet HOT 4 CLOSED

I must admit I haven't actually used the library yet. I found it in awesome-source-generators list.
Discriminated unions is something I try to replicate in C# quite often and I found that your library is the closest to how I would do it :) It seems like that it's evolved somehow since then.

I prefer making the base class abstract and the cases sealed as I don't think that an instance of Animal would make sense without actually being either Dog or Cat in my example. If approached through abstract base, StatusCode (in your example) would have to be extended in each case and it makes the whole thing ugly. I do see exhaustive Match as a big benefit of your approach. However, I do believe that switch is important to make the library more approachable and idiomatic.

TL;DR: trade offs :) I can see how your approach works and if you'r ok with it then there's no need in my suggestion.

from dunet.

I actually didn't know that partial can set abstract. I tested with this in mind and it does work :)
The common property accessor would make case construction more uniform but I guess it's not a big deal. Consider your example:

var one = new HttpResponse<string>.Ok("Hello") { StatusCode = 200 };
var two = new HttpResponse<string>.Ok(200, "Hello");

one.StatusCode;
two.StatusCode; // if all cases have a property named StatusCode of int

Feel free to re-open if you find it a useful upgrade :)

Overall, a great library!

from dunet.

Hey, I really appreciate you taking the time to contribute your idea!

I am a big fan of how typescript treats union types as well.

What do you see as the benefit of supporting this pattern over just declaring a member in the union record itself? For example, I've done something like this at work:

[Union]
public partial record HttpResponse<T>
{
    // A status code is part of all HTTP responses.
    public required int StatusCode { get; init; }

    public partial record Ok(T Content);

    public partial record BadRequest(string Message);

    public partial record ServerError;
}

I'd use it something like this:

using var client = new HttpClient();
var httpResponse = await GetContentAsync(client, "/some-api");

var message = httpResult.Match(
    ok => $"Success ({ok.StatusCode}). Content: '{ok.Content}'",
    badRequest => $"Bad request ({badRequest.StatusCode}). Error message: '{badRequest.Messsage}'";
    serverError => $"Server error ({serverError.StatusCode})."
);

Console.WriteLine(message);

public static async Task GetContentAsync(HttpClient client, string endpoint)
{
    using var response = client.GetAsync<SomeType>(endpoint);
    using var contentJson = await response.Content.ReadAsStringAsync();
    var content = JsonSerializer.Deserialize<SomeType>(content);
    return new HttpResponse.Ok(content) { StatusCode = response.StatusCode };
}

from dunet.

I prefer making the base class abstract and the cases sealed as I don't think that an instance of Animal would make sense without actually being either Dog or Cat in my example. If approached through abstract base, StatusCode (in your example) would have to be extended in each case and it makes the whole thing ugly. I do see exhaustive Match as a big benefit of your approach. However, I do believe that switch is important to make the library more approachable and idiomatic.

The source generator actually makes the union record abstract and its variants sealed behind the scenes for you. :)

TL;DR: trade offs :) I can see how your approach works and if you'r ok with it then there's no need in my suggestion.

Sounds good. Would love to hear your feedback!

from dunet.