The presence of toString on error makes it far too easy to ignore errors

[sameerajayasoma]

if (orderPayload is json) {
             string orderId = orderPayload.Order.ID.toString();
}

The type of the expression orderPayload.Order.ID is json | error. Now because the programer has used toString(), the error goes unnoticed. I think this can be a potential problem. I.e., programmer errors.

[jclark]

This really undermines the error checking.

6.20 in the spec says "If the static type of expression is a subtype of some basic type with identifier B, and the module lang.B contains a function method-name then M is B. The identifier for a basic type is the reserved identifier used in type descriptors for subtypes of that basic type, as listed in the Lang library section." But in this case the expression is not a subtype of a basic type. So the spec actually disallows this. But what the spec says is too strict, because it would disallow using it on a value of anydata.

So we need to fix up 6.20 to have some rules on how unions are handled, and those rules need to disallow unions with error and non-error.

[jclark]

Let's do this together with #499.

[jclark]

The only functions this is a problem for are toString and toBalString in lang.value, which both take arguments of type any|error. Another approach to solving this is to split each of these into two functions

• one in lang.value, which takes an argument of type any
• one in lang.error, which takes an argument of type error

This allows us to have the natural rule in 6.20 for lang.value functions: you can have a union type that is a subtype of the argument type specified in the function signature.

[jclark]

My comment in #350 (comment) was mistaken. There's another bullet in the spec for method-call-expr that covers this:

Otherwise, M is value.