Multiple return values

[mit-mit]

A partner team has requested support for multiple return values for functions, for example:

Future<double> lat, long = mapService.geoCode('Aarhus');
double lat, long = await mapService.geoCode('Aarhus');

[Markzipan]

This feature is related to parallel assignments, which has been raised a couple of times before.

A problem with over-encouraging the use of multiple returns (with multiple types) is that they're not very self-documenting. In Python, it's easy to creep into patterns like:

def get_box_data(...):
	...
	return (((x1, y1), (x2, y1), (x1, y2), (x2, y2)), (r, g, b, a), z)

This function returns the corners of a rectangle, its color, and its depth buffer value. At this point, it would be better off explicitly stored in an object.

Golang enforces some rules on multiple returns to avoid this behavior (among other reasons).

func test() (int, int) {
  return 1, 2
}

var a, b int
a = test() // ERROR
a, b = test() // Okay; a = 1, b = 2
a, b = test(), 2 // ERROR
a, b = b, a // Okay; a = 2, b = 1
fmt.Println(test()) // Okay; prints '1 2'
fmt.Println(test(), test()) // ERROR

Additionally, Golang doesn't allow you to unpack tuples. This avoids some confusing patterns such as:

def test(): 
  return 1, 2

*(a, b), c = 0, *test()
# a = 0, b = 1, c = 2

which is valid Python.

Adopting a stricter system similar to Golang's may be a reasonable tradeoff:

1. Multiple return types can only be specified in the function signature. Return statements can only specify multiple returns from within functions with multiple return types (and their counts must be equal).

   // Valid
   (int, List<int>) myfunc() {
       return 0, [1, 2, 3];
   }
   
   // Identical to above
   (int, List<int>) myfunc() {
       return (0, [1, 2, 3]);
   }
   
   // Invalid
   myfunc() {
       return 0, [1, 2, 3];
   }
   

2. Multiple return types must specify "actual" types (not nested multiple return types).

   // Invalid
   (int, (int, int)) myfunc() {
      ...
   }
   

3. It is illegal to invoke a function with multiple return types alongside operands. That is, a function with multiple return types must fully satisfy its enclosing function/operation.

   (int, List<int>) myfunc() {
       return 0, [1, 2, 3];
   }
   
   void f1(int x, List<int> y) {
   	  ...
   }
   
   void f2(int x, List<int> y, int z) {
      ...
   }
   
   int a;
   List<int> b;
   int c;
   
   a, b = myfunc(); // Valid
   a, b, c = myfunc(), 0; // Invalid
   f1(myfunc()); // Valid
   f2(myfunc(), 0); // Invalid
   

[mdebbar]

It would be great if Dart had builtin support for a tuple type, and provided syntactic sugar for destructuring tuples:

typedef LatLng = Tuple(double, double);

class MapService {
  Future<LatLng> geoCode(String name) {
    // ...
  }
}

var mapService = MapService();

// This is valid:
var latng = await mapService.geoCode('Aarhus');
var lat, lng = latlng;

// This is also valid:
var lat, lng = await mapService.geoCode('Aarhus');

This way we could avoid the complexity of multiple returns. The only thing we need now is to enable the syntactic sugar for destructuring tuples. We could also use fixed-length lists instead of tuples here, but I believe tuples provide a better type primitive.

[GregorySech]

Another way might be going the Standard ML way and just define product types like this:
type LatLng = double * double
If introducing another keyword doesn't seem worth it:
typedef LatLng is double * double;
this with #83 could also allow Dart to have full blown pattern matching feature that came up also in #27.

edit: missing column.

[bjconlan]

Yes! Destructuring! I think leaving the typesystem alone for this is fine. Array seems like a good enough default, (if packing results in an array) and recast to a tupleN type on assignment (as mentioned above).

I would just like to mention the addition of some nicer destructuring patterns (well better than JavaScript's anyway) and more inline with those found in clojure. (https://gist.github.com/john2x/e1dca953548bfdfb9844) specifically the 'rest' like behavior.

[sureshg]

Kotlin uses the data class (value class) to implement the destructing and multiple return values (https://kotlinlang.org/docs/reference/data-classes.html#data-classes-and-destructuring-declarations). This is not perfect but works in most of the cases. Would be great if dart has built in support for value types.

[andreashaese]

See also #207

[Meai1]

I think we really need multiple return values in Dart. How can we say that Dart is type checked if I'm forced to return List and then like in the stone age, do a list lookup one by one and assign it to proper named variables, casting to the right object including all the danger that comes with list array access and casting.
I mean surely this is a horrible state of affairs:

    List returnValues = branchValid();
    bool branchValid = returnValues[0] as bool;
    String branchType = oldBranchValidity[1] as String;

[natebosch]

How can we say that Dart is type checked if I'm forced to return List

I've never been forced to do this - nothing has prevented me from writing a class that contains correctly typed fields for each value I want to return.

[Meai1]

@natebosch crazy to make a class just to return something

[GregorySech]

@Meai1 he probably means a Couple<T, Q> class which can be reused. It's not pretty but it's nothing crazy.

[bjconlan]

Yeah, if we're doing types I think @GregorySech pointed out the common solution for the scenario (tupleN generics) but destructuring is more about shapes (but I guess have to be realised as types at some point, explicitly or otherwise)