E.x on error value should access error detail record field

[sanjiva]

Example:

type HttpError error <”http-error”,
   record {
      string message;
      error cause?;
      map<anydata> otherStuff?;
   }
>;

error e0 = error ("something)"
HttpError e1 = error (message = "shit happened", cause = e0);

To access the message today we have to do this:

io:println ("Ooops: ", e1.details().message);

Can we allow:

io:println ("Ooops: ", e1.message);

I think the compiler can validate this correctly.

[jclark]

Yes, I think that would work fine. If we do this, we should also make ?. operator work also.

[jclark]

This suggestion led me to a long and productive train of thought:

#169 (comment)

[jclark]

There's a complication. Consider

json j = 3;
var v = j.x?.message;

json is laxly typed, so j.x is compile-time OK but evaluates to an error e. Now if we make the change suggested in this issue, e?.message on an error will be OK resulting in the message field of the detail record or nil.

So the semantic has to be more that E.x is desugared into E.detail().x when E is a subtype of error.

[jclark]

This interacts with nominal typing #413. If the error reason string becomes a brand, and we introduce branded records, then access to the fields of the error detail record should become similar to access to the fields of a branded record.

[jclark]

I think we should not do this:

• with the change in Error constructor syntax is vulnerable to typos #393, the message and cause, which are the two most common fields, are available directly on error
• it confuses the user model that the error is a wrapper around the detail record
• it gets complicated when used with lax typing as explained in this comment E.x on error value should access error detail record field #221 (comment)

[jclark]

We decided not to do this.