RFC: implement #6614, destructuring in formal arguments

[JeffBezanson]

This is a fairly straightforward feature, allowing you to write e.g. filter(((a, b),)->isodd(a), dict) (with #23311).

There are a couple edge cases:

• Currently I don't allow putting types on the tuple elements, e.g. f((x::T, y::S)) = .... That could be used to imply a Tuple{T,S} argument type, but destructuring works with any iterable, not just tuples. Also, for (x::T) in itr has always implied x::T = element, which does conversion (and generators do the same). So we should eventually decide which behavior, if any, to use.
• You can, however, declare the type of the argument as a whole, f((x,y)::Tuple{...}). The weird thing is that f((x,y)::Pair) works, since you can destructure Pairs, even though (x,y) looks like a tuple. This is probably just something we have to live with.

[StefanKarpinski]

Nice. How would you feel about the (a => b) -> body syntax I mentioned in the other PR?

[JeffBezanson]

It opens a whole new can of worms --- (a, b) can piggyback on the existing meaning of (a, b) = ..., but (a=>b) = ... doesn't have a meaning yet. I'm not sure what it should do exactly.

[StefanKarpinski]

Fair enough. In this context it would be convenient if it destructured a single argument that is a pair. But I can see that in other contexts it might be more convenient if it matched two arguments. But I think the former interpretation has more symmetry with the input form where it's a single pair.

[JeffBezanson]

Well, I wouldn't want it to match two arguments. We could lower f(g(x,y)) = ... to f((x,y)::g) = ..., but we have to decide how many cases that can apply to (any function call? just certain operators?) and what the protocol is for extracting parts. It's not necessarily ideal to keep using iteration as the only means of destructuring.

[JeffBezanson]

@vtjnash Pointed out to me that python used to have this feature, and removed it in python 3. There is some interesting reading here: https://www.python.org/dev/peps/pep-3113/

Overall, I'm not really convinced by the arguments against this. The first (and seemingly main) argument is that in function f((x,y)) tools that reflect on argument names can't see that x and y are arguments. However, if the feature is removed then you need to rewrite your code to function f(arg); x,y = arg, which has the same problem. It seems to me the solution is just not to think of x and y as arguments, and understand that the feature is a shortcut for adding local variable assignments.

Another issue for python is that all arguments can be passed by name, so you might indeed want to call such a function as f(x = ...) and it won't work. That's more of a problem, but not relevant to julia.