Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider the return type in overload resolution #820

Open
gusty opened this issue Dec 17, 2019 · 7 comments
Open

Consider the return type in overload resolution #820

gusty opened this issue Dec 17, 2019 · 7 comments

Comments

@gusty
Copy link

@gusty gusty commented Dec 17, 2019

Consider the return type in overload resolution

I propose we add a mechanism (attribute or language construct) to consider the return type in overload resolution.

The existing way of approaching this problem in F# is to add a dummy parameter with the type of the return type and call the function with its default value.

Pros and Cons

  • More control over overload resolution
  • Less cases leading to ambiguity resolution compile-time errors
  • Better type inference, since type inference is better when the return type is taken into account.

The disadvantages of making this adjustment to F# are:

  • Adding an extra modifier attribute or a language construct.
  • It's work.

Extra information

Estimated cost: S-M

Related suggestions: #819 #821

Affidavit (please submit!)

Please tick this by placing a cross in the box:

  • This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
  • I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

  • This is not a breaking change to the F# language design
  • I or my company would be willing to help implement and/or test this
@abelbraaksma

This comment has been minimized.

Copy link

@abelbraaksma abelbraaksma commented Dec 18, 2019

For C# 9 I read somewhere that they're going to support return type covariance (returning a more specific type than expected at the call site, though I didn't check the details). It might be related, not sure, I don't fully grasp your proposal yet ;).

@gusty for clarification, what kind of code would currently not compile, and after this change would compile successfully? Could you elaborate with some examples?

@robkuz

This comment has been minimized.

Copy link

@robkuz robkuz commented Dec 19, 2019

@gusty I would love this feature very much. However why an additional lang construct or attribute?
Shouldnt that be the proper case in anyway?

type Runner =
     static member Run(x: string): int = 0
     static member Run(x: string): Boolean = false

let an_int: int = Runner.Run("0")
let a_bool: Boolean = runner.Run("false")
@gusty

This comment has been minimized.

Copy link
Author

@gusty gusty commented Dec 19, 2019

@abelbraaksma see @robkuz did already an example ;)

@robkuz I would love to, but that would ago against the specs (not just F# spec, also C# and possibly other langs) and more importantly it might be a breaking change.

@robkuz

This comment has been minimized.

Copy link

@robkuz robkuz commented Dec 19, 2019

@gusty well if the Spec is wrong or nonsensical it should be tossed, shouldnt it? ;-)
but yeah if this is the only or the fastest way ... then ...

@gusty

This comment has been minimized.

Copy link
Author

@gusty gusty commented Dec 19, 2019

Sure, let's leave it open to make it as default. Anyway I'm not 100% it would be a breaking change, because not having it normally leads to the ambiguos overload resolution error.

@charlesroddie

This comment has been minimized.

Copy link

@charlesroddie charlesroddie commented Dec 22, 2019

Is there a use case for this? An example where it would not be better to rename the method?

I suspect that this code should probably be ruled out as a style restriction, and if it fails to compile, even better.

@gusty

This comment has been minimized.

Copy link
Author

@gusty gusty commented Dec 22, 2019

An easy example, all generic applicatives and monads require a set of overloads, based solely on the return type. See here an example.

A more complex scenario: many overloaded functions improve type inference if the return type is taken into account.

I suspect that this code should probably be ruled out as a style restriction, and if it fails to compile, even better.

Hope you're not willing to forbid overloads ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.