In none of the languages you mentioned do stdlib functions either return an iterator or a list depending on whether you feed it into an iterator operation; in none of the languages you mentioned can a fully-generic return as a method receiver be inferred by the name of the method. It has nothing to do with how well you explained it; it just doesn't exist. Every single thing you are complaining about exists in all of the languages you brought up, although Perl does a small portion of that in some cases depending on the variable sigil (ie still not guessed).

Your post is a restricted special case of "it would be great if any old sequence of characters compiled correctly and the compiler just read my mind". Wouldn't it just, but the rules of programming languages exist for more purposes than just annoying the user.

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.