Decide on status of `new {}`

[odersky]

The Current State

The current Dotty implementation allows to leave out the parent of an anonymous class if it is known from the expected type. So the following compiles

trait C { type T; val m: T }
def f(x: Int): C = new { type T = Int; val m = x }

This avoids duplication since we would have to write otherwise

def f(x: Int): C = new C { type T = Int; val m = x }

This matters if the name C is long or there are type parameters.

Likewise, the following also compiles:

def g(x: C) = ???
def test = g(new { type T = String; val m = "" })

That's a bit more dubious since the name C does not appear anywhere in the call, so this looks like a pure structural new that uses reflection for dispatch.

None of this is currently specified except for a single line in syntax.md:

SimpleExpr ::= ... |  ‘new’ TemplateBody

A Possible Alternative: Structural Instances

• Use C with { ... } as an anonymous class
• Allow C with { ... } as the result type of a def without having to write a RHS, mimicking what we do for givens.

This means the first example above would be written like this:

trait C { type T; val m: T }
def f(x: Int): C = C with { type T = Int; val m = x }

which can be abbreviated to

def f(x: Int): C with { type T = Int; val m = x }

In fact the abbreviated form is more useful than the original forms since the result of f is known to bind T to Int.

There was an explanation about this in #10538. Quoting here:

This has another interesting consequence. Taken by itself, can we give a meaning to T with { defs }? In fact, this does make sense as an alternative syntax for an anonymous class. If we go down that path, we can truly get rid of all vestiges of new in the syntax (over time, not for 3.0).

Taking this further, we can now see the following (approximate) equivalence:

given x: C with { ... }     ~~~      given x: C = C with { ... }   ~~~    given x: C = new C {...}

So, : C with {...} is approximately : C = C with {...}, and it avoids the repetition. In fact : C with {} is more useful than : C = C with {...} since it keeps any refinements in {...} in the type. So it's more like a RHS = new {...} and an inferred result type. In fact it's even better than that, since an anonymous class new { ... } is subject to avoidance, but : C with { .. } creates the class alongside the given instead of in its right hand side. This means that members freshly introduced in {...} are visible in the result of the given. To see the difference, consider this code:

class C
given c: C with
  def foo = 1

given d: C = new C { def foo = 1 }

def test =
  c.foo  // OK
  d.foo  // error: `foo` is not a member of `d`.

Now, one intriguing step further is whether we want to allow the same convention for normal defs. I.e

def foo(x: Int): T with {...}

as a slightly more powerful alternative to

def foo(x: Int) = T with {...}

or, using new

def foo(x: Int) = new T {...}

with the same expansion as for the given. This would give us parameterized objects, or functors in the SML sense, without having to define a class. It also gives a nice way to avoid duplication between return type and RHS while stile having an explicitly defined return type.

What to do?

We should not adopt both new {...} and structural instances. I believe structural instances are ultimately a lot more powerful and useful than new {...}, in particular since they give us the power of object (which can define new members not covered in the extends clause) with parameters.

So our choices are:

1. Spec new {} for 3.0 and close the door for structural instances.
2. Adopt structural instances for 3.0, including spec and implementation. We might be too late for this.
3. Drop new {}, keeping the door open for structural instances later.
4. Same as (3), except we put new {} under an experimental flag for now.

[sjrd]

The structural instances for normal defs won't fly in practice. You'll need to invent a name for the anonymous class thing, that will be part of the public ABI, but there is no way to do that for overloaded methods. We get away with it in givens because they already have a generated name and they can't be overloaded. It won't work for defs.

[odersky]

I mentioned it in passing in the other thread: The idea would be to use a name derived from the method name itself. I.e.

def f(x: T): R with { ... }

would translate to

class f$(x: T) { ... }
def f(x: T): f$ = new f$(x)

The derived name for the class could use the same construction as what we use for defining a module class. Yes, that means that only one overloaded variant can use a structural instance. But I would argue that's OK. A function like the only above is really
a parameterized object. So it's not too restricting to say that there can only be one parameterized object per name.

One thing we could discuss is whether the syntax should not be

object f(x: T) extends R { ... }

In either case, the mapping would be the same, and either syntax would obviate the need for new {...}.

[LPTK]

@odersky What would the difference between

object f(x: T) extends R { ... }

and

class f(x: T) extends R { ... }

be, given that the latter can now be constructed with syntax f(x)?

[odersky]

@LPTK There are some differences, but maybe they are not important enough.

• Methods can be inline
• Method can implement abstract methods

But likewise we could ask: What are use cases for

def f(...): T = new {}

?

[LPTK]

• Methods can be inline

But inlining it would just produce an instantiation expression, which is the same as constructing the class directly with creator application.

• Method can implement abstract methods

Right. On a side note there is currently this funny feature in both Dotty and Scala 2 where implicit classes can implement abstract methods, since they automatically create methods of the same name as the class:

scala> trait T { def C(x: Int): Any }
// defined trait T

scala> object O extends T { implicit class C(val x: Int) }
// defined object O

I wonder if it would make sense to generalize that to all classes (create a homonymous method when it implements something).

---

But likewise we could ask: What are use cases for

def f(...): T = new {}

?

The main use case for "naked" new is to simplify DSL implementations that rely on scope injection. Instead of:

class Inject[A,B,C] { def foo ... }
...

dsl(new Inject[S,T,U] { ... foo ... })

we can write:

dsl(new { ... foo ... })

Though that's not such a big deal, now that Scala 3 can infer class constructor arguments (Scala 2 could not!). We can even reduce the boilerplate by using a renaming import:

import lib.{ Inject => I }

dsl(new I { ... foo ... })

So I'm not sure it's that useful to support naked new, though it's a nice feature to have that sometimes comes in handy.

[odersky]

I am not sure how I feel about the scope injection use case. So maybe it's better not rush it in and require an experimental language flag for now. What do others think?

[sjrd]

This is not important enough to justify an experimental language flag. Either we remove it, or we make it official.

---

My main use case for new { ... } would be in code that interoperates with JavaScript APIs taking "config objects". A typical example is the fetch function (though it is a very common pattern in JS APIs), which you might want to call as follows in JS, for example:

const responsePromise = fetch('flowers.jpg', {
  method: 'GET',
  headers: {
    'Content-Type': 'image/jpeg'
  },
  mode: 'cors',
  cache: 'default'
});

When we give it a facade type in Scala.js, it looks as follows:

@js.native @JSGlobal
def fetch(url: String, init: FetchConfig): js.Promise[Any]

trait FetchConfig extends js.Object {
  var method: js.UndefOr[String] = js.undefined
  var headers: js.UndefOr[js.Dictionary[String]] = js.undefined
  var mode: js.UndefOr[String] = js.undefined
  var cache: js.UndefOr[String] = js.undefined
  // and a dozen more, not used in this example
}

so that we can call fetch in Scala.js as

val responsePromise = fetch("flowers.jpg", new FetchConfig {
  method = "GET"
  headers = js.Dictionary(
    "Content-Type" -> "image/jpeg"
  )
  mode = "cors"
  cache = "default"
})

and have everything typecheck.

Note that I had to invent a trait name FetchConfig for the type of the config. This name is irrelevant; it is not specified or documented in the original JavaScript API, nor used in the original JavaScript snippet. In fact, it does not exist at all in JavaScript.

This name is pure Scala.js fiction. I shouldn't have to worry about it when I write my Scala.js code calling Fetch (not anymore than I want to deal with names of given instances, for example).

So in Scala.js I would like to use new { ... } here instead:

val responsePromise = fetch("flowers.jpg", new {
  method = "GET"
  headers = js.Dictionary(
    "Content-Type" -> "image/jpeg"
  )
  mode = "cors"
  cache = "default"
})

and have it all still typecheck.

[odersky]

OK. It is useful, and not exactly what a hypothetical with would provide. So let's keep it.
I have added #10759 to remind us that it needs to be documented.