Throughts on how generic conversions should be named?

[AZMCode]

Implicit parameters are a feature I've yet to be fully comfortable with, but I've realized a couple of places where there might be limitations. Particularly when it comes to conversions.

Currently, the conversion functions of the language are written as the name of the type they convert to. However, this makes it difficult to use implicit parameters to refer to "a conversion function to a generic type".

I feel like this issue could be addressed by simply naming all conversion functions the same name by convention, since the correct function can be picked via implicit parameters, but I feel like that could mess with type inference in non-generic use.

Another way to solve it could be to allow the name of the type referred to by a generic type be used in the implicit parameter name, but that means adding a whole new language feature just to deal with this, admittedly niche, issue.

What other ways could be pursued to address this?

[TimWhiting]

Can you explain further / with an example what you mean by "conversion function to a generic type." There might be a better way to accomplish what you want, but right now I only vaguely understand what kinds of problems you are looking to solve using generics, implicits, and static overloading.

[AZMCode]

Oh. I'm trying to implement type-generic modular arithmetic, and while it isn't a requirement per se, it would be nice to convert some constants (like 1, 0 2, etc) into the generic type for comparison/operations. This particular issue could be solved by defining some constants in the standard library though.

I can think of a couple examples from the standard library though, where the type is partially or completely specified in the function/constant identifier, and there are similar ones for other types. min-int*, for* and fold*, for example. Trying to write a type-generic function utilizing any of these would be a bit of a pain due to above.