Resource constructor result typing

[guybedford]

Resource types don't currently have the ability to define constructors as having custom result return error types.

For this reason, custom static constructors are likely usually preferable for resources since most constructor patterns with non-trivial arguments will want argument validation.

Would it make sense to consider result overloading only for resource constructors? I believe most languages should come with the ability to return an error from a resource constructor.

[lukewagner]

Great point and thanks for filing! This same issue came up in another context, with the same tentative conclusion, so agreed this is a good thing to add right after Preview 2. I think the change here is just to loosen the validation criteria for [constructor]-prefixed functions to additionally allow a return type of (result (own $R) (error T)) (for any T). With this, languages with new and exceptions can continue to have new call the constructor whereas other languages can emit the appropriate idiom for fallible constructors.

[AaronFriel]

Static methods also return T instead of GuestT, so this workaround doesn't work:

interface foo {
  resource bar {
    fallible-ctor: static func() -> result<bar, string>
  }
}

I think this might be better than allowing constructor to return result<>, because languages such as JS cannot emit fallible constructors, but can admit fallible static methods that return this(). This allows making the constructor private and serving what some languages would call a smart constructor over the wire.

[lukewagner]

Sorry, I didn't follow your point regarding static methods, T, GuestT, and what's wrong with the workaround you showed?

because languages such as JS cannot emit fallible constructors

IIUC, the current prototyped JS bindings for result return types is that the failure case corresponds to an exception (with the result's error payload stored as a field on the exception object) and the success case just returns the success payload value directly (no wrapped with anything). Given this, a fallible constructor should I think map just fine to (throwing) new.