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

[SR-1420] Provide compiler warning when shadowing generic type #44029

Open
swift-ci opened this issue May 5, 2016 · 4 comments
Open

[SR-1420] Provide compiler warning when shadowing generic type #44029

swift-ci opened this issue May 5, 2016 · 4 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented May 5, 2016

Previous ID SR-1420
Radar rdar://problem/17866188
Original Reporter BMc68 (JIRA User)
Type Bug
Status Reopened
Resolution
Environment

OSX El Capitan 10.11.4
Xcode 7.3

Additional Detail from JIRA
Votes 2
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: 4a05a8615ae667cb3fe37027d209d99e

is duplicated by:

  • SR-1841 QoI: Warn when shadowing generic type parameters
  • SR-2538 swiftc doesn't give helpful errors when names of generic variables collide

relates to:

  • SR-5838 Can't infer type of inout parameter for an operator
  • SR-8524 Shadowing in protocols leads to difficult to find bugs
  • SR-5701 Segmentation fault with accidental generic parameter shadowing

Issue Description:

The swift compiler should warn users when they are accidentally shadowing generic type parameters in their code.

Code

public struct Promise<T, U> {
    var futureValue: T -> U

    public func then<T,U,V>(closure: U -> V) -> Promise<T, V> {
        return Promise<T, V>(futureValue: {
            input in
            let value = futureValue(input)
            return closure(value)
        })
    } 
}

Error

error: cannot invoke value of type 'T -> U' with argument list '((T))'
        let value = futureValue(input)

What I'd want to see, more or less

warning: shadowing generic type T in function Promise.then
warning: shadowing generic type U in function Promise.then   
error: cannot invoke value of type 'T -> U' with argument list '((T))'
        let value = futureValue(input)

Related Stack Overflow Question

@swift-ci
Copy link
Collaborator Author

Comment by Blake (JIRA)

In Xcode 8.2.1, Swift 3 the compiler now outputs this.

```
Playground execution failed: error: Scratchpad.playground:2:38: error: single argument function types require parentheses
public func then<T,U,V>(closure: U -> V) -> Promise<T, V> {
^
()

error: Scratchpad.playground:5:25: error: type of expression is ambiguous without more context
let value = futureValue(input)
^~~~~~~~~~~~~~~~~~

error: Scratchpad.playground:6:20: error: closure use of non-escaping parameter 'closure' may allow it to escape
return closure(value)
^

Scratchpad.playground:2:29: note: parameter 'closure' is implicitly non-escaping
public func then<T,U,V>(closure: U -> V) -> Promise<T, V> {
^
@escaping
```

@belkadan
Copy link
Contributor

Reopening this because we still don't talk about the shadowing specifically.

@stephencelis
Copy link
Contributor

Just chiming in with a +1 since this (and its dupes) have been open for awhile. I've hit this problem many times over the years. Sometimes I immediately recognize the issue, sometimes it takes a few minutes, and sometimes I need the eyes of a colleague to jolt my brain into proper diagnostic order, so I really wish the compiler would take care of this for me 🙂

struct Func<A, B> {
  let run: (A) -> B
}

extension Func {
  static func lift<A, B>(_ f: @escaping (A) -> B) -> Func {
    return Func(run: f)
  }
}

The diagnostics:

Cannot convert value of type '(A) -> IO<B>' to expected argument type '() -> IO<>'
Fix it: Insert ' as! () -> IO<>'

Maybe we lose the current fix-it, add warnings or errors per overshadowed generic (is there ever a reason to want to shadow a generic parameter?), and they can have fix-its to remove the shadowing?

@belkadan
Copy link
Contributor

belkadan commented Jan 7, 2019

Part of the inaction around any shadowing warnings is that there hasn't been a general discussion of what kinds of shadowing are okay and what aren't (a very subjective question), and that has the potential to be a sprawling discussion. I'm not sure we can agree to just deal with a little bit of it and ignore the rest, but if there's anywhere where it would make sense it would be this case: a member of a generic type whose generic parameters are exactly the same as the type's.

@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
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

3 participants