Use of type cast to ignore errors

[jclark]

Given:

function foo1() returns string|int;
function foo2() returns string|int|error;

Both of these will compile:

int x = <int>foo1();
int x = <int>foo2();

This feels like silently ignoring the error. Another example is

json j;
string x = <string>j.x.y.name;

With lax static typing, type of j.x.y is json|error, and the cast to <string> results in the error being implicitly converted to a panic.

This relates to #350, #487 and #488.

[sanjiva]

I think our mindset was that the use of cast here is not to ignore the error but rather to assert confidence in the value being of that type, even though it may be of another.

I don't think we want to lose that.

[ThisaruGuruge]

We kinda used the following practice when it comes to type checking

string|error result = getSomeStringOrError();
if (s is error) {
    // handle error
}
string s = <string>result;

This is to reduce the long if else ladders and improve the code readability. This example is a minimal one, but there are some complex cases. This may effect it.
@daneshk @shafreenAnfar

[jclark]

@ThisaruGuruge That one is #73

[jclark]

I think the rule should be that you "cannot cast away error", meaning that if there are errors in the type before the cast, there must be errors in the type after the cast. The before/after errors don't have to be the same: it's fine to cast to a more precise error. Note that the language already provides checkpanic which has the same effect as casting to a type with all errors removed.

[jclark]

We decided we are ok with the proposal in #489 (comment)