DU 2022 10 19

Notes for October 19th, 2022

The theme of our first meeting was collecting scenarios that we think can be improved by discriminated unions, so we have an idea of what problems we're trying to solve.

PageState

public enum PageState
{
    NotLoaded,
    Loading,
    Loaded,
    Errored
}

public class Page {
    PageState state;
    
    // used when state is Loaded
    PageData data;
    
    // used when state is Errored
    string errorMessage;
    
    
    public View Render() {
        switch (this.state)
        {
            case PageState.NotLoaded:
                return ShowLoadButton();
            case PageState.Loading:
                return ShowLoadingSpinner();
            case PageState.Loaded:
                return ShowData(this.data!);
            case PageState.Errored:
                return ShowErrorMessage(this.errorMessage);
            default:
                throw Unreachable;
        }
    }
}

class PageData { }

class View { }

• UI App scenario
• Different page states - state machine transition
• Has some state fields that are only applicable when in a particular state
  • Could be represented as a type hierarchy as well
• Should be able to remove throw Unreachable;
• Would you be able to define a PageState.Show()?
  • This is the OO fashion, we're really talking more functional.

Web APIs

[HttpGet(Name = "GetWeatherForecast")]
public IActionResult Get(int id)
{
    return id % 2 == 0
        ? Ok(Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = Summaries[Random.Shared.Next(Summaries.Length)]
        }).ToArray())
        : NotFound();
}

app.MapGet("/minimal-dus/{id}", Results<Ok<string>, ProblemHttpResult> (int id) => {
    return id % 2 == 0
        ? TypedResults.Ok("Valid ID")
        : TypedResults.Problem("Invalid Id");
});

• IActionResult is very common in MVC
  • Worked around in minimal APIs by using Results<TypeA, TypeB, ... TypeN> (lots of versions of this, like ValueTuple)
    • All Results are IResults
  • Does it matter if it's anonymous in some fashion or explicitly declared by the user?
  • What about subsets of the full union?
    • Just Ok or NotFound?
• Error recovery: Optional or Result<TOk, TErr>

IDE APIs

• IDE: message passing where something could be a subset of a larger group of possibilities
  • Heterogeneous data - not a subset of a larger type hierarchy.
  • Painful and not checked today: can only be one of the tuple elements, but we have to pass around and check these in a non-straightforward fashion

Optional

• Could we have semantics such that we can have a Optional<T> in the BCL
• Maybe an syntactic shortcut for this?
• Result type would be useful for type metadata decoding: currently we throw exceptions.
• Some sort of syntax help for short-circuiting these would be nice, a-la ? in Rust.
  • Would hopefully be able to apply not just to Ok/Result monads, but other kinds as well.

Type Hierarchy subsets

https://github.com/dotnet/roslyn/blob/7b6fc9baa013ceb935973144543bcc422b8234d2/src/Compilers/CSharp/Portable/Binder/LockOrUsingBinder.cs#L44-L45

• More of an anonymous scenario
• Subset of a larger union - homogenous data
• Large DUs, such as SyntaxNode or BoundNode, are almost never useful as those large subsets. Smaller subsets, often defined ad-hoc, are usually what we want to work with.
• Large unions might be hard to add to existing projects without large refactorings. Some projects might be able to do this, but many won't. The BCL won't for their public APIs.

Generalized semantics

• Are there advantages to targeting existing scenarios, and then having syntax that can make it easier to do?
  • Likely yes: will have wide compatibility with existing code.

Next meeting

For next time, we will look at the commonalities in these scenarios and start looking at strategies for representing them.