Currently function types are slightly asymmetric with results having an extra single-unnamed-result option. As #356 points out, we could make params and results fully symmetric by saying that both could either be a list of all-named- or all-unnamed types. I think that topic requires some more discussion to motivate and understand the implications for bindings generators in various languages.
In the meantime, though, I don't think anyone uses or even knows about named multi-return -- the much more common thing to do is to return a tuple or record (almost always wrapped in a result). I think this means we can expect to see
an ad hoc mix of multi-return and tuple/record in practice which seems like needless inconsistency (and wasted time arguing over what if any convention there should be). It also seems like this path will be either unimplemented or untested in current bindings generators, which bodes poorly if anyone ever does decide to use this feature.
Thus, this PR proposes that, at least until we decide to go for full symmetry, we lean into the asymmetry (which is already present) and disable this additional case of named multi-return that (afaik) noone is using. If however anyone is using and appreciating named multi-return, I'd be very interested to hear about it! (I'll leave this PR open for a while to collect feedback.)
Currently function types are slightly asymmetric with results having an extra single-unnamed-result option. As #356 points out, we could make params and results fully symmetric by saying that both could either be a list of all-named- or all-unnamed types. I think that topic requires some more discussion to motivate and understand the implications for bindings generators in various languages.
In the meantime, though, I don't think anyone uses or even knows about named multi-return -- the much more common thing to do is to return a
tupleorrecord(almost always wrapped in aresult). I think this means we can expect to see an ad hoc mix of multi-return andtuple/recordin practice which seems like needless inconsistency (and wasted time arguing over what if any convention there should be). It also seems like this path will be either unimplemented or untested in current bindings generators, which bodes poorly if anyone ever does decide to use this feature.Thus, this PR proposes that, at least until we decide to go for full symmetry, we lean into the asymmetry (which is already present) and disable this additional case of named multi-return that (afaik) noone is using. If however anyone is using and appreciating named multi-return, I'd be very interested to hear about it! (I'll leave this PR open for a while to collect feedback.)