pseudo-overloading functions with enums

[erickt]

I've been working on a couple different serialization libraries, and I often find taking advantage of enum variants living in a different namespace than types. It's really nice to declare:

enum t {
  int(int),
  str(str),
  vec([t]),
}

fun to_str(x: t) {
   alt x {
     int(i) { int::to_str(i) }
     str(s) { s }
     vec(v) { "[" + str::concat(vec::map(v, to_str), ",") + "]" }
   }
}

But calling these functions can get a bit noisy, especially when using arrays:

to_str(vec([int(1), str("foo"), vec([int(2), str("bar")])]))

I'm not sure if we're planning on supporting overloading functions, but what if the type system could automatically box arguments if an enum name is the same as the type? As in allowing us to write:

to_str([1, "foo", [2, "bar"]])

and automatically convert it to the boxed form from above. I'm not sure if this would play well with generics or typeclasses, but it'd really clean up some code I'm writing. Is this possible, or even a good idea?

[marijnh]

This looks like a poster-child use-case for impls. Wouldn't that be a much simpler and more efficient way to do it?

iface to_str { fn to_str() -> str; }
impl of to_str for int { fn to_str() -> str { int::str(self) } }
impl of to_str for str { fn to_str() -> str { self } }
impl <A: to_str> of to_str for [A] { fn to_str() -> str {
    "[" + str::connect(vec::map(self, {|e| e.to_str()}), ", ") + "]"
} }

fn main() { [1, 2, 3].to_str(); }

[nikomatsakis]

@elly wanted this too.

I agree with @marijnh that impls are good here, except that they cannot accommodate something like ["hi", 1].to_start().

[marijnh]

except that they cannot accommodate something like ["hi", 1].to_start().

Using boxed iface values, they can.

[nikomatsakis]

Using boxed iface values, they can.

Yes, I know... what I meant is, you can't write it that way. We'd have to auto-coerce to a boxed iface. I think that so long as boxed iface allocations require allocation this isn't such a good idea, but maybe with #1567 it would be more reasonable.

[catamorphism]

Looks like "revisit this when #1567 is done" to me.

[graydon]

This bug is effectively asking for implicit-conversion operators. At the point we're at now, I'm .. pretty disinterested in those as a feature; they have a lot of expressive power but they interact with a lot of already-overcomplex pieces of the language. Also, IME they tend to bring a lot of headache to maintenance programmers / readers when trying to figure out what code does (for example, in C++).

I think we have a bunch of reasonable ways of doing polymorphic code now that are not too painful, and could grow more (for example, I think we're nearly at the point of being able to write the any type in plain library code, using visitors), as far as expressing the motivating case for the bug itself. So I'm going to close with effectively a WONTFIX here, but if you vigorously disagree, reopen and state why.