Try/auto tupling #51
Try/auto tupling #51
Conversation
Auto-tupling should satisfy the following spec. 1. An application `f(args)` where `f` is a non-overloaded method which has a single, non-repeated parameter as its first parameter list and where args consists of two or more arguments is expanded to `f((args))`. 2. A constructor pattern `C(args)` where `C.unapply` is a non-overloaded method which has a single, non-repeated parameter as its first parameter list and where args consists of two or more arguments is expanded to `C((args))`.
Eliminated all "Dotty deviations" which were due to lack of auto-tupling.
|
I would much rather not have auto-tupling at all. It is to arity checking of method application/pattern matching as dynamic typing is to Scala. This is why ()-parameter-list-insertion is deprecated in 2.11. |
|
I don't understand. Wasn't auto-tupling supposed to disappear? Wasn't it judged as being more harmful than not? |
|
The scala bug regarding starting with deprecating () insertion scala/bug#8035 |
|
Note that compared to Scala 2.11, auto-tupling is more restricted. In particular, the new auto-tupling does not do () insertion. Also, it does not apply if the function in question is overloaded. This avoids problems like accidentally picking an overloaded variant taking an Object parameter when some other variant is intended but the right number of parameters is not passed. Other advantages: There is a simple spec (given in the first commit). I would like to complement this with auto-detupling for lambdas. Specifically, if we have a lambda (x, y) => expr and the expected type is of the form A => B, then expand the lambda to { case (x, y) => expr } I believe if we do this in addition to restricted auto-tupling we can avoid much of the confusion surrounding tupled vs n-ary functions. |
|
Ok, I'll mull this over a bit. (Same with other PR.) |
|
My initial concerns are:
|
|
On a related (brainstorming) note: how about supporting patterns in argument definitions (so the conversion would be opt-in, but more general)? becomes: Also, would be nice to be able to abstract over Tuple arity using HList. |
|
This also suggests an alternative interpretation for auto-tupling along the same lines as bridge methods. A method that opts in to auto-tupling, could have a "bridge" method auto-generated that unpacks the n-tuple and forwards to the n-ary overload. |
|
Regarding the initial concerns:
Yes, but this is nothing new. Other things stop working as well. E.g. adding an overload means that a closure argument needs explicit parameter types.
I hope not. The aim of auto-tupling is just to avoid weird looking ((a, b, c)) syntax. Nothing more general is desired.
Agreed up to the point that every conversion is risky. But note that the proposed conversion is much better behaved than tryTwice: There's one specific point, and a specific set of conditions where it is applied, and there's no backtracking involved. |
|
Pattern in argument definitions could be neat, but require much more thought, I guess. To come to a conclusion here, I propose to put the conversion or its absence under a language import. The default of that import is whatever Scala 2.x is to make migration easier. So initially it would be import language.noAutoBoxing to change the default. We can easily flip the default later if desired, so that the import would become import language.autoBoxing |
|
I'm okay with putting this under a flag, though I'd suggest |
I know, but that's not a very strong argument for introducing another surprise. I guess I'm dubious about the benefit vs cost ratio on this one. |
|
Yes, of course. autoTupling it is. |
|
Subsumed by #75 |
Tests are represented by the dotty codebase itself, where previously modified occurrences of auto-tupling are re-instantiated.