tubthumper8

What do you mean by "failing tests", are you talking about runtime code? TypeScript erases all types at compile so these wouldn't affect tests. Unless you meant "compile errors" instead.

I've noticed LLMs just slap on "as any" to solve compile errors in TypeScript code, maybe this is common in the training data. I frequently have to call this out in code review, in many cases it wasn't even a necessary assertion, but it's now turned a variable into "any" which can cause downstream problems or future problems

Who said that anyone is absolved of the responsibility to write tests for business logic when using Rust? I struggle to see anything in the comment you replied to that is anywhere close to claiming this

Not sure what you mean here by "most JavaScript parser rejects null" - did you mean "JSON parsers"? And why would they reject null, which is a valid JSON value?

It's more that when building an API that adheres to a specification, whether formal or informal, if the field is supposed to be a JSON array then it should be a JSON array. Not _sometimes_ a JSON array and _sometimes_ null, but always an array. That way clients consuming the JSON output can write code consuming that array without needing to be overly defensive

Inline breakpoint, the same way you set a breakpoint on an expression in any language

The "Error Return Trace" described in the next section down also seems like an interesting alternative to a stack trace, possibly solving the same problem with less noise.

How well does it work in practice?

I've read elsewhere that one idea for the zero value of sum types is not making it nillable, but rather making the zero value as the 0th variant of the sum type (and if it has associated data, the zero value of that as well).

It's weird, but does align with design decisions that have already been made.

So if there was an `Option[T]` with variants `None` and `Some[T]`, the zero value would be `None` because that's the zero-th variant

Can you expand more on the Gang of Four comment? Which separation does GoF describe that is applicable in this context? And what is the definition of a "concern"?

Can you do it for functions defined by other people, or only for functions that you defined?

I'm thinking in the general case, but motivated by this example of a 3rd party function that accepts a SQL query as a string, and we'd like everywhere in our codebase to stop using that and instead use the 3rd party function that accepts the query as a t-string

Do the python type checkers / linters / whatever have the ability to warn or error on calling certain functions? That would be nice to eventually enforce migration over to the newer functions that only take a t-string template

>that's what discriminated unions (aka product types aka algebraic data types)

Just an FYI, discriminated unions are not product types, they are sum types. It's named so because the total number of possibilities is the sum of the number of possibilities for each variant.

Ex. A sum type Color is a PrimaryColor (Red, Blue, Yellow) OR a SecondaryColor (Purple, Green, Orange), the total number of possibilities is 3 + 3 = 6.

For a product type, if a ColorPair is a PrimaryColor AND a SecondaryColor, the total number of possibilities is 3 * 3 = 9

Both sum types and product types are algebraic types, in the same way that algebra includes both sums and products.

For the standard library, I'm curious for the family of TryParse kind of functions, since those are well modeled by a sum type. Maybe adding an overload without an `out` argument would give you back a DU to `switch` on

There's also going to be quite a big ecosystem / standard library difference between languages that had fundamental type system features since the beginning vs. languages that added fundamental features 23 years later.

Imagine all the functions that might return one thing or another, which was inexpressible in C# (until this proposal is shipped), will all these functions release new versions to express what they couldn't express before? Will there be an ecosystem split between static typing and dynamic typing?