[swift-dev] Location of "indirect" declaration modifier

[Chris Lattner]

On Dec 11, 2015, at 7:03 AM, Slava Pestov via swift-dev <swift-dev at swift.org> wrote:
> With your proposal, the fact that the entire tuple payload can be matched by a pattern implies that ‘indirect’ has to become a formal type in the language, since you will now be able to write down a value of type '(indirect ArithmeticExpression, Int)’, for example. It also raises the issue of how these indirect values are wrapped and unwrapped, since now the ‘indirect ArithmeticExpression’ is itself a value.

Yes.

> An alternative is to make ‘indirect’ a non-materializable type, like ‘inout’. ‘inout’ can appear inside tuple types, but is not a first class value. This creates lots of special cases for ‘inout’ and you can imagine it will be equally difficult for ‘indirect’.

Incidentally, I’m of the opinion that we’re modeling this wrong, on both the call and the declaration side.  

Decl side: because we historically allowed arbitrary irrefutable patterns in argument lists, the argument list of a AbstractFunctionDecl is represented as a Pattern.  This doesn’t make sense because we’ve since realized that that was a bad idea, and now argument lists have their own parsing logic and can only support specific trivial kinds of patterns.  It is also annoying because general patterns cannot use “inout” or internal vs external parameter names, so argument lists are making real patterns more complicated.  I plan to fix this by splitting AbstractFunctionDecl onto a custom data structure, allowing this to be simplified.

On the call side, we have analogous representation damage, where ApplyExpr takes a function and an argument, and the argument is usually a tuple, sometimes a parenexpr, or sometimes neither!  This makes a lot of stuff more complicated, and forces “&” in argument lists to be represented as InOutExpr, and that Expr needs a type (InOutType).  If we changed ApplyExpr to take a structured argument list, we could dispel this complexity (eliminating InOutType and InOutExpr completely, along with a ton of corner case bugs).  This would lead to a lot simpler code throughout the compiler as well.

Fixing these are on my todo list somewhere :-) and I’ve heard that ChrisW is also interested in this area.

-Chris