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

Jump to bottom

[SR-2450] Wrong min() function is selected for call #45055

Open
krzyzanowskim opened this issue Aug 22, 2016 · 7 comments
Open

[SR-2450] Wrong min() function is selected for call #45055

krzyzanowskim opened this issue Aug 22, 2016 · 7 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself feature A feature request or implementation

Comments

@krzyzanowskim
Copy link
Contributor

Previous ID SR-2450
Radar rdar://problem/17368791
Original Reporter @krzyzanowskim
Type Bug
Status Reopened
Resolution
Environment

Xcode Version 8.0 beta 6 (8S201h)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, LanguageFeatureRequest
Assignee None
Priority Medium

md5: 29ef06ccf0e63a3fe41d3cead2c2f4cf

Issue Description:

see snippet below

extension Collection where Self.Iterator.Element == Int
{
    func foo() -> Int {
        return min(1,2) //Error: Argument passed to call that takes no arguments
    }

    func boo() -> Int? {
        return self.min()
    }
}

there is no local function min(x:y:) therefore I think compiler should automatically choose right Swift.min(x:y:) function, rather than trying to use local min() [no arguments].
@rudkx
Copy link
Member

rudkx commented Sep 24, 2017

This was fixed a while ago.

@NevinBR
Copy link
Contributor

NevinBR commented Sep 25, 2017

I still see an error for this in Xcode 9.0 running Swift 4.0, has it been fixed since then?

@rudkx
Copy link
Member

rudkx commented Sep 25, 2017

Sorry I was too quick in closing this out without any explanation.

The local min shadows the global min, so there is nothing to "fix" here, but a diagnostic was added to try to make it clear what was happening, and to provide a fixit for it.

The proposed change in behavior here would have to go through swift-evolution.

@rudkx
Copy link
Member

rudkx commented Sep 25, 2017

Leaving it open and under the tag LanguageFeatureRequest for now.

@jepers
Copy link

jepers commented Mar 28, 2018

This is essentially the same issue as this: https://bugs.swift.org/browse/SR-7018
isn't it?
But note that SR-7018 has been closed (and resolved as invalid) since it is working as designed.

And here's another one:
https://bugs.swift.org/browse/SR-7143

@NevinBR
Copy link
Contributor

NevinBR commented Mar 29, 2018

@jepers, yes you are right. However, @slavapestov has pointed out on the Swift forums that since SE–0111 makes argument labels part of function names, we ought to update the lookup rules so that only functions whose names including argument labels match the call-site are considered.

That is not quite as straightforward as it sounds, because we have to account for “missing” argument labels due to default values and trailing closures, as well as “extra” arguments with variadic parameters. Nonetheless, it is still eminently achievable, and appears necessary as part of SE–0111.

Even if the current behavior might technically have been “working as intended” prior to SE–0111, nowadays it ought to be considered a bug.

@jepers
Copy link

jepers commented Mar 29, 2018

OK, thanks!

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself feature A feature request or implementation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rudkx @krzyzanowskim @jepers @NevinBR