spike: demo the storage api in C#

[malandis]

This demonstrates the Store API in C#. Because C# has significant support for implicit casts, we can greatly simplify the developer experience when interacting with the multitude of types that go in and out of the store.

By using implicit casts on the way in, we only need one Put method that takes a StoreValue. The StoreValue type defines casts from various types to StoreValue. That way a developer can write:

await client.PutAsync("my-store", "my-key", 3.14);

and the runtime will create a StoreValue from the double. The compiler detects any invalid casts.

Similarly on when we retrieve data with GetAsync, we can return a Success that has a StoreValue. The user can benefit from implicit casting in the reverse direction. They can write

var getResponse = await client.GetAsync("my-store", "string-value");
if (getResponse is StoreGet.Success success)
{
    string value = success.Value;
}

If the cast is incorrect, the .NET runtime will throw an InvalidCastException.

By storing the type in StoreValue, we the developer can do pattern matching exhaustively over that. The compiler notifies the developer when the pattern matching is not exhaustive.

[cprice404]

theoretically the right-hand-side of these could be a code block, correct? Allowing us to put in some logging or throw a different error type if we decide to, etc.?

Not saying we should change it from what you have here, just wanted to understand our options.

[malandis]

Yes. The right-hand side here is just a shorthand when the function body is a single statement. We can have a multi-statement block instead.

[cprice404]

kewl

[cprice404]

This one makes me want to raise the same question I raised on your JS PR about whether we should be modeling Success/Error as algebraic types, or just return the value directly and throw an exception for errors. In this case, that would simplify the code down to a try/catch block with multiple catch clauses, as opposed to an if+try.

Probably it'd be too inconsistent to make that dramatic of a change for this Client given that it will be living in the same SDK, but I'm just trying to think through what I would advocate for here if it was a greenfield product.

[malandis]

Same comment re: the JS API. I like the shorthand but there's forward compatibility concerns.

[cprice404]

In what sense? Are you talking about the case where the server changes in the future to support additional response types?

[malandis]

Nevermind -- I was confusing the inner value type with the Success object. You're saying we can return the Success object or bust. We are free to add more data to Success if we do that.

[cprice404]

have you seen this before?

https://spencerfarley.com/2021/03/26/unions-in-csharp/#improvements-in-c

[malandis]

It rings a bell. I think C# 9 wasn't out at the time when I saw this or it was a preview. When thinking about this I consider the lowest common denominator.