SIPs 24 and 25 tracking

[dickwall]

SIP-24 Repeated By Name Parameters, SIP-25 Trait Parameters

In public review until next meeting

Status re: compiler implementation

[dickwall]

Is implementation in another compiler, e.g. dotty or typelevel scala, sufficient proof of implementability?

[SethTisue]

I'll make sure that I discuss these SIPs with the rest of the Scala team (@adriaanm, @lrytz, @retronym) before the next SLIP comitttee meeting. We'll discuss both the proposals themselves, and possible timing (2.12? 2.13? Dotty? etc).

[dickwall]

From @SethTisue on gitter:

as promised, I discussed SIP-24 and SIP-25 with the rest of the Scala team at Typesafe (Lukas, Jason, and Adriaan) I can report in more detail at the next meeting, but here’s a quick summary. SIP-24. the SIP doesn’t give much motivation and no use cases, so we were left thinking “does anyone actually want this?” (well, Dmitry’s comments on the Dotty ticket are sort of a use case, sort of.) we don’t object for Dotty, but to do this for Scala 2, we’d want better motivation. as for technical concerns, the question of whether the semantics are like Seq[Function0[…]] or Function0[Seq[…]] would need to be sorted out. the former seems more powerful and natural, but there’s no obvious syntax for forcing the individual items.

everyone likes SIP-25, and we’ll try to keep an eye on how it’s going in Dotty, with an eye towards making sure the trait encoding changes we’re making for 2.12 are designed with this eventuality in mind (even though the 2.13 is almost certainly as early as this SIP could be adopted for scalac)

[dickwall]

Comment from @odersky on gitter:

Regarding SIP 24. The use case where we stumbled on it is not yet relevant for Scala. It was: If you have an inline method m and a call m(e) then in order to keep semantics you should evaluate the expression e before calling the method. But sometimes we want the argument to be passed unevaluated. This can be achieved by defining the method like this:

inline def m(x: => T)

But that trick does not work if the original parameter is a vararg. But more specifically, there seems to be no reason why we want to have the restriction. Arbitrary restrictions complicate the language. If we can remove them at little cost, why not do so?

question of whether the semantics are like Seq[Function0[…]] or Function0[Seq[…]] would need to be sorted out. the former seems more powerful and natural, but there’s no obvious syntax for forcing the individual items.

That question is answered in the SIP; it is Function0[Seq[…]]. Since we want to simplify the language, we should lift the restriction with the least amount of additional complications possible.

[dickwall]

Comment from @adriaanm on gitter:

As a tie breaker (Seq[Function[]] v Function[Seq[]]), I agree we should consider which way around is least surprising. The closest type you can currently write is () => A * B, which parses as () => (A*B). If you think of postfix operators having the same precedence as infix ones, Function0[Seq[A]] is the most regular interpretation, syntactically, and thus hopefully what users will expect intuitively.

[dickwall]

Request status update for Sept 10th SLIP meeting, do we have consensus on inclusion, and possibly a target Scala release yet if inclusion is desired?

[SethTisue]

This is now being handled under the new SIP process.