So… overloads that conflict because only the retur...

# language-proposals

[benleggiero]

So… overloads that conflict because only the return types differ. I’m not sure how deep into bytecode the erasure goes, but I would like to propose we allow this. Perhaps the first iteration might have to mangle the JVM names to make this happen, in which case it should come with an @ annotation that says “Yes, I know this will make things weird for other JVM languages but I really want this”. Hopefully it’s possible without name mangling, though.

The reason I propose this feature is because it would be essential for the Collection Literals KEEP as it’s currently written. https://github.com/Kotlin/KEEP/pull/112#issuecomment-390830008

[Ruckus]

I don't see how you can. What if I just call the function and ignore the return?

[rrader]

than the code will not compile

[Ruckus]

That seems like a pretty bad user experience.

[benleggiero]

This would, like I mention, be an opt-in feature for methods whose return value really matters. You wouldn't, for instance, just call a toString() method for funsies and ignore the string. Likewise, you wouldn't make two println() functions that return different types.

[Ruckus]

Lets face it, assuming your users will only use a feature in the ways you like is fallacy 🙂

[benleggiero]

Then why have var? Why make anything non-nullable? Why inherit? Heck, why not put everything in global scope?

Saying that a feature doesn't belong in a language because it can be abused or ignored is fallacious and doesn't belong in this channel.
Now, if there's an argument that it's difficult not to abuse it (like compiler directives) , that is okay. But I don't think that's what you're saying

[Ruckus]

Wow, I was just being facetious. I have no intention to quash your idea, and I never said it doesn't belong. I just wanted to add my opinion to the mix.

[benleggiero]

Oh okay. Sorry; sometimes I can’t tell 😅

[Ruckus]

It's all good. Text is not the best medium for sarcasm.