Change syntax of given whitebox macros

[odersky]

Status quo

inline def whiteBox1 <: T = ...
inline given whiteBox2 as _ <: T = ...

Critique

• Syntax is not consistent
• You could argue that the first syntax is too quiet and also misleading since at first glance whiteBox1 is in the position where you would expect to see a type.
• _ <: T is technically wrong (or, rather, old style) since it suggests a lambda. We are after an existential instead.

Proposal

Write ? <: T (analogous to a wildcard type argument) to express both forms of whitebox macros. I.e.

inline def whiteBox1: ? <: T = ...
inline given whiteBox2 as ? <: T = ...

Opinions?

[smarter]

? <: T makes me think I can put something other than ? on the left which is not the case. If we need to change the syntax I would rather use an extra keyword to denote whiteboxity (I think whitebox is fine since it's well-established Scala jargon).

[odersky]

Or transparent?

[abgruszecki]

I actually like the ? <: T syntax - it expresses the "unknown subtype of T" concept well.

Reg. trying to replace ? with another type - to me doing that would result in something that reads like nonsense, so I'm not sure if very many people will try to do that. Consider:

inline def foo : ? <: String === "define an inline foo that returns some subtype of String"
inline def foo : "a" <: String == "define an inline foo that returns "a", which is a subtype of String"

[smarter]

The problem is that:

inline def foo : ? <: String

is very different semantically from:

inline def foo : List[? <: String]

The latter is not whitebox at all, even though it uses a very similar syntax.

[abgruszecki]

Hm, you may be right and it may be too cute. How would the keyword syntax look? Like this?

inline whitebox def foo : String = …

[smarter]

whitebox inline def I'd say, whitebox is a modifier of inline.

[abgruszecki]

The part that I am slightly miffed about is that we would lose the "this is not an actual type annotation" suggestion that the current syntax foo <: String expresses. Might not be a big loss, all things considered.

[odersky]

I'd go for transparent inline. whitebox is too much expert speak. Also, it works better in conjunction with blackbox but we do not have that one as a modifier.

[therealcisse]

How about ?

inline def whiteBox1 : ?String
inline given whiteBox2 as ?T = ...

This was propose and rejected for nullable types.

[nicolasstucki]

Finally, I have always thought that this feature deserved a flag. We currently have no way to know if an inline method is whitebox or not after it is typed.

[milessabin]

Scala 2 accidentally treats an empty refinement as "do not widen" indicator. Could we make that official and use it here,

inline def foo : String {} ...

[nicolasstucki]

We should have a syntax where not widening would not happen by mistake.