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

[swift-ci]

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]

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]

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

[stephencelis]

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]

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.