Multi-file ADTs

[joan38]

Hi,

Here is a proposal to add the permits keyword on sealed traits and classes to allow the implementation of multi file ADTs:

sealed class Shape permits Circle, Square, Rectangle

This would work similarly to Java 17: https://docs.oracle.com/en/java/javase/17/language/sealed-classes-and-interfaces.html

We have multiple instances were we dropped the sealed keyword just because the file was too big.
Some other are using a trick with traits: https://github.com/BalmungSan/scala-multifile-adt

Thanks

[som-snytt]

The use case falls under "prefer composition to inheritance". Delegation to private implementation classes is made trivial by export:

package shapely

sealed trait Shape:
  def area: Double

case class Circle(x: Int, y: Int, r: Int) extends Shape:
  private val circled = Circled(x, y, r)
  export circled.*

case class Square(x: Int, y: Int, s: Int) extends Shape:
  private val squared = Squared(x, y, s)
  export squared.*

Instead of "multifile ADT", I think a more generally useful feature would be "multifile compilation unit".

That would allow a huge class with its huge companion object to be in two files. (That has been requested previously.)

No doubt this could be implemented in a build tool, since the compiler is nominally agnostic about how a compilation unit is sourced.

[joan38]

I like this idea

[joan38]

However I wonder how are the imports going to be interpreted. The order these files in a compilation unit will change if the code is compilable or even its the behavior potentially

[joan38]

@som-snytt How would you achieve the same composition with export and object in enum? Body seem to be forbidden in enum cases

EventSource.scala:

enum EventSource[ParsedEvent]:
  def decode(inputEvent: Any): ParsedEvent

  case Foo extends EventSource[String]      with JsonEventSource
  case Bar extends EventSource[Array[Byte]] with AvroEventSource

JsonEventSource.scala:

trait JsonEventSource:
  self: EventSource[String] =>
  override def decode(inputEvent: Any): String = ""

AvroEventSource.scala:

trait AvroEventSource:
  self: EventSource[Array[Byte]] =>
  override def decode(inputEvent: Any): Array[Byte] = Array.empty

https://scastie.scala-lang.org/7pkiShbETrms1xCTNUE0tA

[arie-benichou]

I like the idea and here is my proposal to it :

Proposal: Cross-File Sealing for Sealed Traits with Explicit Subtype Declaration

Motivation
Currently, Scala's sealed traits require all subtypes to be defined within the same file. This limitation restricts the flexibility of sealed traits, especially in larger projects with modular codebases. This proposal aims to introduce a mechanism for cross-file sealing, allowing subtypes to be defined in separate files while maintaining the benefits of compiler optimization and exhaustive pattern matching.

Proposed Solution
Introduce a new syntax for sealed traits that allows explicit declaration of subtypes using an applyTo clause. This clause would list the fully qualified names of the classes or objects that are allowed to extend the sealed trait.

Example

import com.example.MyClass1
import com.example.MyClass2
import com.example.MyClass3

sealed trait MyTrait {
  // ... trait definition ...
} applyTo(com.example.MyClass1, com.example.MyClass2, com.example.MyClass3)

To improve conciseness, the following syntactic sugar could be used, which is equivalent to the applyTo() version:

import com.example.MyClass1
import com.example.MyClass2
import com.example.MyClass3

sealed trait MyTrait {
  // ... trait definition ...
} (com.example.MyClass1, com.example.MyClass2, com.example.MyClass3)

Explanation
The import statements ensure that the specified subtypes are visible within the scope of the MyTrait definition.
The applyTo clause explicitly declares the allowed subtypes, enabling the compiler to:
Verify that the listed subtypes exist and extend MyTrait.
Perform exhaustive pattern matching checks.
Apply optimizations based on the closed set of subtypes.

Benefits
Cross-File Sealing:
Allows subtypes to be defined in separate files.

Compiler Optimization:
Maintains the benefits of compiler optimization and exhaustive pattern matching.

Clarity and Maintainability:
Provides a clear and explicit declaration of allowed subtypes.

Semantic Consistency: The use of applyTo aligns with the semantic of the apply method, making the syntax more intuitive.

Enforcement of Subtype Restrictions
A critical aspect of this proposal is ensuring that the compiler enforces the subtype restrictions defined in the applyTo clause. If a class or object defined outside of the listed subtypes attempts to extend the sealed trait, the compiler should generate a compilation error. This enforcement is essential for maintaining the guarantees of exhaustive pattern matching and compiler optimization.

Example

// In a separate file:
class UnauthorizedClass extends MyTrait // Should result in a compilation error

Potential Considerations
Requires changes to the Scala compiler to recognize and process the new syntax.
Modifying the compiler for this feature should not introduce significant risks. Sealed traits have a relatively simple AST (Abstract Syntax Tree) representation. The compiler can leverage existing mechanisms for type checking and analysis, with minor adaptations to handle the explicit subtype declarations. This localized nature of the change minimizes the potential for unintended side effects on other parts of the compiler.

Use Cases
Modeling complex domain entities with variations spread across multiple files.
Creating extensible frameworks with a closed set of extension points.
Enhancing the safety and reliability of pattern matching in large codebases.

Next Steps
I would appreciate feedback from the Scala community and the Scala Team on this proposal. If there is sufficient interest, I am willing to contribute to the implementation of this feature.

Thank you for your consideration.

[soronpo]

You can open a new thread and refer to the old one

[som-snytt]

@arie-benichou your proposal motivated me to catch up with the -source:future features for "modularity". CanExtend may be expressible in currently proposed syntax. I would expect a class companion to declare given CanExtend to permit extension. Maybe the class has a deferred given member that can be satisfied only if an appropriate CanExtend is available.

[arie-benichou]

@som-snytt
Thanks for your message.
Do you have a link to the thread you are talking about so i can better grasp the context ?
What I understood is that somehow this feature request and its proposal could be applied in another context too that involves a compilation flag -source:future.
Could you please explain, or give an example if there is no thread yet talking about it ?

[som-snytt]

@arie-benichou for inspiration, https://dotty.epfl.ch/docs/reference/experimental/modularity.html

[arie-benichou]

@soronpo
Thanks. I will do like this.