V: Generics that extends an interface

Created on 2 Nov 2020  路  3Comments  路  Source: vlang/v

Rust, if you have programmed in it, allows you to specify a generic to a specific trait. I don't remember what this feature is called, but it looks like this:

trait Operable {
    fn operate() -> String;
}

fn gen<T: Operable>(operator: T) {
    println!(operator.operate());
}

The purpose of this is to make sure that the type that will be passed to the function fulfills a certain function or field, to avoid making use of non-existent things.

In V this could be elegant, because with this we could tell the compiler that we expect a type that implements one (or more) specific interfaces.

interface Operable {
    operate() string
}

interface Hack {
    hackme()
}

fn gen<T: Operable + Hack>(v T) {
    println(v.operate())
    v.hackme()
}

What do you think about this?

Feature Request

Most helpful comment

yup, that will be implemented.
might look like:

interface Operable {
    operate() string
}

interface Hack {
    hackme()
}

fn gen<T = Operable + Hack>(v T) {  // or even extends?
    println(v.operate())
    v.hackme()
}

@medvednikov has to decide.

All 3 comments

yup, that will be implemented.
might look like:

interface Operable {
    operate() string
}

interface Hack {
    hackme()
}

fn gen<T = Operable + Hack>(v T) {  // or even extends?
    println(v.operate())
    v.hackme()
}

@medvednikov has to decide.

Hi all, great idea :-) .
What do you think only to align to sum types syntax (using the "|" to identify all interfaces allowed) ?
I think in TypeScript there are a lot of interesting ideas about this (and generics related things: constraints, etc) and a common syntax, see here ... hope it's a useful suggestion. Bye

using the "|" to identify all interfaces allowed) ?

For sum types that means 'one of these types'. Here we want all of the interfaces to be satisfied.

Go proposes to use no punctuation: GenericType InterfaceName:

type Stringer interface {
    String() string
}
func Stringify[T Stringer](s []T) (ret []string) {

I don't think they support listing more than one constraint for the same type, but we could allow them inline, e.g. T Operable Hack.

BTW I don't think we need to support type list constraints:

type Float interface {
    type float32, float64
}

We have sum types so we could use type Float = f32 | f64 if we want to support this for a type constraint.

Was this page helpful?
0 / 5 - 0 ratings