Generics vs Sum Types

[eptx]

Example 1 below fails as it looks like matching on primitives with generics is not available? Is this expected behavior or just not implemented yet?

Example 2 succeeds using Sum types. What other considerations are there when designing with Vlang generics vs sum types?

//example1 fails
fn whatami<T>(a T) {
    match a {
        int {println('int:$a')}
        string {println('string:$a')}
        else {println('other')}
    }
}
whatami<int>(10)


//example 2 success
/*
type Arg = int | string | f64

fn whatami2(a Arg) {
    match a {
        int {println('int:$a')}
        string {println('string:$a')}
        f64 {println('f32:$a')}
    }
}

whatami2(10)
whatami2('test')
whatami2(7.2)
*/

[Wajinn]

Hmmm... Vlang's sum types are already doing what you wish generics in Vlang to do (in the example), so the user is not missing that functionality. Additionally, what you appear to want to do with the generics example, can presently be done as below.

fn whatami<T>(a T)  {
	match typeof(a).name {
        'int' {println('int:$a')}
        'string' {println('string:$a')}
        else {println('other')}
	}
}

whatami<int>(10)

[eptx]

Ah that's the V-way with generics. Thanks. In this case it seems sum types are cleaner. But per the 2nd question...what considerations would you recommend? For example, is using sum types considered more V-idiomatic? Are there sets of problems better approached with sum types over generics and visa versa?

[JalonSolov]

It depends on what you want to do, really. Sum types give you a way to constrain the types that can be used, just by what is or isn't added to the sum type.

Generics, however, only generate code to handle exactly the types you use.