[WITHDRAWN] Pre-SIP: Context Classes (Types)

Scala Improvement Process
1

The motivation of this SIP is similar to the context functions feature that was introduced in Scala 3: to reduce context propagation verbosity in the method definition site (e.g., many function having using Ctx blocks all over the place). This proposal simply expands upon the context function types concept and syntax to define the semantics for context class inheritance.

Here is a context function type example:

trait Ctx
type CtxFunc[T] = Ctx ?=> T

def id(arg: Int): CtxFunc[Int] = arg //equivalent to def id(arg: Int)(using Ctx): Int = ...

I propose that we enable extending Ctx ?=> T if T is a class and propagate the context argument to class definition:

trait Ctx
type CtxCls[T] = Ctx ?=> T

class Foo
type FooCtx = CtxCls[Foo]

class ID(arg: Int) extends FooCtx //equivalent to class ID(arg: Int)(using Ctx) extends Foo

Of course, like in context function types, we can define multiple context arguments with (C1, C2, ..., Cn) ?=> T.

Observation: If accepted, we should just name X ?=> T context types, instead of context functions and define the semantics for methods and classes.

2

With a regular function,

class Bar extends Int => String { ... }

means that Bar is a subclass of Int => String and can be used anywhere Int => String can be used.

But

class Id(arg: Int) extends Ctx ?=> Id {... }

seems like a way to define the constructor, which isn’t exactly a parallel, is it?

3

After further thought, I’m withdrawing the proposal. Too much magic, and my use case can be covered with a compiler plugin and mutation. Ugly solution, but better than creating perhaps surprise semantics.

2 Likes