> You may notice no language on the planet does this. That is because it is bad.

Perhaps I've explained this poorly, but C#, Java, Perl, & Haskell (and I'm sure others as well) do versions of this already...

You even seem to imply that Swift does, though I have almost no experience directly with Swift.

The vast majority of times it is NOT ambiguous. The compiler can flag it, IFF you want it to.

If you're coming from Python and you want to ease your learning experience, you probably don't want to hit several brick walls before you can do anything...

If you have an enterprise codebase, you probably don't want to allow anything to be compiled that could be ambiguous, so you can force that mode of compilation (and likely should)...

I don't know of any major language which have progressive modes of compilation like this. I think people will find it useful.

Maybe it'll be a disaster. Time will tell. The whole point is to intelligent design the modes such that you can't ever get a MASSIVE surprise "upgrading" from one mode to the next, any error that is too hard to resolve basically automatically / through selecting options needs to be dealt with at the easiest mode.

▲

pie_flavor 2 hours ago | parent [-]

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.

	▲	onlyrealcuzzo 2 hours ago \| parent [-]
		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.