I think you're stuck completely on the iterator example or only named functions (which makes sense, since that's all you've seen), rather than several languages supporting various types of polymorphic returns and/or downstream target typing (mainly in lambdas or with sigils).

Certainly if you allow a language do something like:

```rust

fn foo() -> i32 { 42 }

fn foo() -> String { "42" }

```

That would be a nightmare.

But you can have something like:

```rust-ish

@eager_fallback(String[])

fn split(s: String, separator: Char) -> String::Iterator { ... }

```

Which, essentially, defaults to calling collect to an Array for you when bound to a variable, or when chained to a function that doesn't take an iterator but does take a String Array. And in a different mode of compilation, there are no fallbacks (you're back to Rust).

Sure, I don't know a language that supports polymorphic return exactly on `.split()`, but there are languages that support all of the different mechanisms to do this intelligently.

You're assuming the implementation is going to do a number of things that would cause either code bloat or force ambiguity (and potentially a number of other assumptions).

I think you're also assuming the type is not resolved until who knows what happens to it, rather than once it's bound.

None of those HAVE to be true.

To the best of my knowledge, for the most common cases, this can be solved, and when it can't, the compiler can flag it.