Support syntax for Anonymous Inline Context Parameters

[japgolly]

Compiler version

3.0.1-RC1-bin-20210406-b0061c4-NIGHTLY

Minimized code

inline def x(using inline ev: Int) = 1 // ok
inline def y(using inline     Int) = 1 // error

Output

[error] 2 |inline def y(using inline     Int) = 1
[error]   |                                 ^
[error]   |                                 ':' expected, but ')' found
[error] one error found

Expectation

Successful compilation.

[odersky]

It would maybe be nice if we could do this, but that's currently not foreseen. inline is a modifier that goes on individual parameters. It's not foreseen to put it on a type. Moving to discussions.

[neko-kai]

Shouldn't this be moved to feature requests instead? I'd rather have one place for "open questions" regarding dotty and currently that place is the https://github.com/lampepfl/dotty-feature-requests issue tracker

[abgruszecki]

@neko-kai yes, it should. Unfortunately it seems a discussion can't be converted back to an issue.

[japgolly]

I don't think this should be moved to feature requests. The way I look at it, anonymous context parameters is already an approved new feature and this is a case of not being able to use a context parameter anonymously.

[japgolly]

erased modifies the parameter clause just like using/implicit. On the other hand inline affects each individual parameter.

@nicolasstucki Many thoughts:

• If erased modifies the entire clause, I think we need to add isErased to TermParamClause in the quoting API
• It's a bit odd and arbitrary to me that erased would affect the entire clause and inline only a param. Wouldn't it make more sense (and be better for end-users) to make erased affect just the param like inline does?
• Wouldn't it be trivial to have the compiler transform (using inline A, inline B) into (using inline x$1: A, inline x$2: B)? Or if it's a bit more complex that than would you mind teaching my why? (Part of me thinking about writing a PR for small things like this.)

[nicolasstucki]

• If erased modifies the entire clause, I think we need to add isErased to TermParamClause in the quoting API

Yes, we should have it. Adding it in #12040.

• It's a bit odd and arbitrary to me that erased would affect the entire clause and inline only a param. Wouldn't it make more sense (and be better for end-users) to make erased affect just the param like inline does?

This restriction is there to support erased function types without having a combinatorial explosion. As it is we already need a function type of each rarity for normal functions, given functions erased functions and given erased functions.

As those functions are generated and erase to a smaller set of function types to might be possible to let each individual parameter be erased or not. This might come with some extra technical challenges.

• Wouldn't it be trivial to have the compiler transform (using inline A, inline B) into (using inline x$1: A, inline x$2: B)? Or if it's a bit more complex that than would you mind teaching my why? (Part of me thinking about writing a PR for small things like this.)

My intuition is that we are only missing the parsing part of the logic. The rest seems to be there.