Type inference for `error` constructor

[rdhananjaya]

Description: Ballerina 1.2.x used to support the construction of user-defined error values using error as the error constructor.

const F = "FOO";
type MyError error<F, record {| string message?; error cause?; string...; |}>;

public function main() {
    MyError e = error(F);
}

With the introduction of functional constructors and distinct types should we still support this inference or is it required to provide the exact type-reference, when constructing values of user-defined error types?

[jclark]

Is any code making using of this inference?

[rdhananjaya]

Found bunch of cases in stdlib code, here is a few

• https://github.com/ballerina-platform/ballerina-lang/blob/10dbfb190ef81e3cec4849fad35a9a0737d1ed49/stdlib/auth/src/main/ballerina/src/auth/auth_errors.bal#L44

• https://github.com/ballerina-platform/ballerina-lang/blob/10dbfb190ef81e3cec4849fad35a9a0737d1ed49/stdlib/http/src/main/ballerina/src/http/auth/utils.bal#L280

[jclark]

In the new design the type-ids (from distinct types) are performing the role that the reason string played in the old design. Previously, if you used error, then you had to specify the reason string; in other words, we never inferred the reason string. Similarly, in the new design I don't think you should infer the type-id: in other words, you should not be able to use error to construct a value of an error type with a non-empty set of type-ids.

So from your first example, this:

public const AUTH_ERROR = "{ballerina/auth}Error";
public type Error error<AUTH_ERROR, Detail>;
function prepareError(string message, error? err = ()) returns Error {
    log:printError(message, err);
    Error authError;
    if (err is error) {
        authError = error(AUTH_ERROR, message = message, cause = err);
    } else {
        authError = error(AUTH_ERROR, message = message);
    }
    return authError;
}

should turn into:

public distinct type AuthError error;
function prepareError(string message, error? err = ()) returns AuthError {
    log:printError(message, err);
    return AuthError(message, err);
}

[sanjiva]

Shall we not support functional constructors in the 1.2.* path? Those are changing so best not to right?

[jclark]

2019R3 and 2020R1 have functional constructors just for errors (so not called functional constructors)

https://ballerina.io/spec/lang/2019R3/#section_6.21

2020R2 adds them for xml subtypes and calls them functional constructors. So I would expect 1.2.* to stick to 2019R3 and 2020R1 here.

[sanjiva]

What I'm suggesting James is that if we haven't yet implemented those features, then not doing them at all.