> I think you’re confused as to what return type polymorphism is, though. It’s the ability to have the compiler infer the type of something from its site of use

> I think you’re confused as to what return type polymorphism is, though. It’s the ability to have the compiler infer the type of something from its site of use. I think you may be confused about what return type polymorphism is tbh. Type inference != polymorphism. Polymorphism is a type-system feature. Type inference is a separate process to ascertain concrete types at compile time. For example, the only type inference that C# really does is `var`: var x = foo(); That is no different to me writing: int x = foo(); (assuming that foo returns an int that is). The compiled version of both of those code snippets are the same. The fact that I specified the `int` directly doesn't make those chunks of code any different. Or, make one less valid. You're right it's absolutely the case that to do this I'd need to specify the types I want to work with, and that's because C# is shit at inferring anything. It doesn't change the fact that the return type is polymorphic for Concat in my example. It's _ad-hoc polymorphic_, and no lack of type-inference will change that. But this still misses the entire point of what I wrote. Which was to counter the point made in your original post: > Once you've got return type polymorphism, you really start to miss it in other languages. Initially I felt I was helping by pointing out that if you're missing it in other (mainstream) languages, then there's absolutely a way of doing it. > The simplest example possible is "mempty" mempty :: a > gets the "default" value of a. Which makes no sense in a language where you need an instance to have polymorphism. And secondly I felt it important to use your example of `mempty` to show how to do it.