trait feature

[linxuanm]

Virgil lacks a notion of interface/capability at the moment, which makes decoupling difficult when writing programs. I have some ideas based on the design of doc/ideas/Traits.v3, and would love some feedback!

Overview

// Represents a class that can be serialized into {T}
// {A} is instantiated to be the implementing type/class of this trait
trait<A> Serializable<T> {
	def fromData(data: T) -> A;
	def toData(self: A) -> T;
}

impl Serializable<string> for i32 {
	def fromData(data: string) -> i32 { return 0; }
	def toData(self: i32) -> string { return "0"; }
}

class ConstStringBox<T>(value: T) {}

impl<T> Serializable<string> for ConstStringBox<T> {
	def fromData(data: string) -> ConstStringBox<T> { return ConstStringBox.new("foo"); }
	def toData(self: ConstStringBox<T>) -> string { return "bar"; }
}

Grammar

This proposal introduces two top-level declarations: trait and impl.

TraitDecl ::= "trait" ( "<" IDENTIFIER ">" )? IdentParam "{" Member* "}"
ImplDecl ::= "impl" ( "<" TypeArgs ">" )? IdentParam "for" IdentParam "{" Member* "}"

A trait defines a set of function signatures that specify shared behavior which types can opt into. A trait block declares required methods without providing implementations.
An impl defines how a type implements a trait by providing concrete implementations for the trait’s declared methods.

Type variables' declaration can include an optional trait constraint to specify that the variable can only be instantiated with a type implementing the trait:

def printSerializable<T: Serializable<string>>(value: T) {
    System.puts(T.toData(value));
}

impl<T> Serializable<string> for i32 { ... }

def main() {
    printSerializable<i32>(16); // ok
    printSerializable<bool>(true); // error: "bool" does not implement "Serializable<string>"
}

[linxuanm]

Member resolution

I'm hesitant on this, but I think that unlike Java's interface, the implementation of a trait should be kept separate from a type's own member functions. For instance

trait Foo {
    def bar() -> int;
}

class Clz {
    def bar() -> int { return 42; }
}

impl Foo for Clz {
    def bar() -> int { return 0; }
}

def extract<T: Foo>(v: T) { return T.bar(); }

def main() {
    var v = Clz.new();
    v.bar(); // 42
    extract(); // 0
}

The benefit of this is to reduce method conflicts (since any type can be opened to implement any trait at anytime) and to explicitly keep capabilities decoupled from the type's definition. However it can also be very cumbersome, as invoking a trait method on a value requires a type variable instantiated to the value's type. In the above example, Foo.bar cannot be invoked on an instance of Clz without a parameterized function extract.