Feature request: Automatically convert a variant to a parameter whenever it's safe to do so

[gabrieldemarmiesse]

Apologies if this does not make any sense, I'm not an expert in language design.

The current issue with Variant:

When we look at Mojo's Variant, we can see that they're not easy to use (compared to, for example, Python's unions).

Because of the internal representation, a function that works with let's say, an Variant, will not accept as argument only one element of a Variant. Currently, we do a trick with Optional[T] in mojo to go around this and have automatic conversion, but that won't work as soon as we work with collections. Consider the following piece of code, which is very common (any serializer is full of this type of functions):

from utils.variant import Variant

fn convert_to_strings(x: DynamicVector[Variant[Int, Float64]]) -> DynamicVector[String]:
    # Stringify all elements in a list
    var result = DynamicVector[String]()
    for i in range(len(x)):
        var value = x[i]
        if value.isa[Int]():
            result.append("An int: " + str(value.get[Int]()))
        else:
            result.append("A float: " + str(value.get[Float64]()))
    return result


fn main():
    var a = DynamicVector[Variant[Int, Float64]]()
    var my_strings = convert_to_strings(a)

    var b = DynamicVector[Int]()
    var my_strings_from_int_only = convert_to_strings(b) 
    # argument #0 cannot be converted from 'DynamicVector[Int]' to 'DynamicVector[Variant[Int, SIMD[f64, 1]]]'

To write intuitive libraries here, and avoid requirering data conversion (which can be slow for arrays), we're a bit stuck, we could use overloads, but that's a lot of code duplication. If I want my function to work with all possible types, I would have to write something like this (if unions were available as a trait):

fn convert_to_strings[T: Int | Float64 | Variant[Int, Float64]](x: DynamicVector[T]) -> DynamicVector[String]:
    ...

But even then, that's very painful, especially if there are more than two types in the variant. With Variant[Int, Float64, String], I would have to write

fn convert_to_strings[T: Int | Float64 | String | Variant[Int, Float64] | Variant[Int, String] | Variant[Float64, String] | Variant[Int, Float64, String]](x: DynamicVector[T]) -> DynamicVector[String]:
    ...

To make sure all possible inputs are supported, without requirering data conversion.

The proposed solution

I hope I'm not missing anything here.
I believe If we have a borrowed argument using a Variant, since the code path would be correct with any combinaison of input types, could the compiler automatically create the correct overloads with all the combinations of types mentionned above. It would ensure that we can write very intuitive functions in our libraries. For example, it would allow us to write easily json.dumps() that accepts many inputs:

fn dumps(value: Variant[Int, Float64, String]) -> String:
     if value.isa[Int]():
        ...
    ...

fn main():
    var a: Int = 4
    var a_str = dumps(a)

    var b: Float64= 8.1
    var b_str = dumps(b)
    
    var c: String = "hello mojo"
    var c_str = dumps(c)

    var a_or_b_or_c: Variant[Int, String](a)
    var a_or_b_or_c_str = dumps(a_or_b_or_c)

I believe it only works with borrowed because if the input is mutable, we might want to modify the type in the input value.

fn dumps(owned value: Variant[Int, String]) -> String:
    if value.isa[Int]():
        value.set[String](str(value.get[Int]()))
   return value.get[String]()

# this can't work if value is an Int (without Variant) because the data type would change.

I hope I was clear enough, and that I'm making sense, and that it will be easier to use variant in the future without forcing data conversion (which can be an issue for arrays).

I guess we could start by having a decorator which does this, to see if people find it useful?

[Moosems]

I partially get what you're saying but maybe simplifying the example a bit further might help 😅? Based on my understanding on both the problem and Mojo as a language this would require a custom trait that can encompass all allowed types but if one doesn't want a custom Int, custom String, etc that seems like it'd make the issue worse rather than better. The example you gave in the beginning however should actually work (it should become valid Mojo IMO) as the Variant should break down given that you're using an Int. If one gives one of the allowed types the Variant part should fizzle away and just leave the accepted type.

[rarebreed]

I would imagine this is a problem with a lack of subtyping in mojo? DynamicVector[Int] should be a subtype of DynamicVector[Variant[Int, Float64]]. In other words, I should always be able to pass in the former, where the latter is accepted.

I suppose you could run into issues with covariance and contravariance though. I'm not even sure what mojo's rules for covariance, contravariance and invariance are. Also, will mojo support structural subtyping of some form? My understanding is that structs will not support nominative hierarchical subtyping relationships (eg OOP style inheritance), but what about structural subtyping (ie, a more formal duck typing)?

I'm not a PLT guy, but wouldn't subtyping solve this problem?