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-6554] Type inference error when applying optional function to optional value #49104

Closed
swift-ci opened this issue Dec 7, 2017 · 6 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself regression swift 4.0

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Dec 7, 2017

Previous ID SR-6554
Radar None
Original Reporter trimm (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

Swift 4.0, Swift 4.0.1

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

md5: d5270fb56c4a13ba96b13a49017fdb53

Issue Description:

public extension Optional {
    public func apply<Result>(_ transform: ((Wrapped) -> Result)?) -> Result? {
        return self.flatMap { value in
            transform.map { $0(value) }
        }
    }

    public func apply<Value, Result>(_ value: Value?) -> Result?
        where Wrapped == (Value) -> Result
    {
        return value.apply(self)
    }
}

Possibly related to bug: https://bugs.swift.org/browse/SR-6509

This works fine under Swift3-3.2.

Actual results:

'apply' produces 'Result?', not the expected contextual result type 'Result?'

Expected results:

The code compiles, compiler infers the type of result for type of Wrapped

@belkadan
Copy link
Contributor

belkadan commented Dec 8, 2017

You're supposed to put the second function in a constrained extension. We don't support constraints on generic parameters in an individual function's where clause.

cc @slavapestov

@belkadan
Copy link
Contributor

belkadan commented Dec 8, 2017

I guess I should put "supposed" in quotes because clearly it used to work, and it seems to again on master. But I didn't think we supported this.

@slavapestov
Copy link
Member

slavapestov commented Dec 8, 2017

There's no way to express what the user wants with a constrained extension, but the construct is supported. The bug is in the expression checker and not in generics.

@slavapestov
Copy link
Member

slavapestov commented Dec 8, 2017

This is related to function parameter list matching behavior which changed in SE-0110. Looks like something got fixed on master along the way. I'll add a test case.

@slavapestov
Copy link
Member

slavapestov commented Dec 8, 2017

Here is the test: #13345

@belkadan I guess this feature is supported now ;-)

@belkadan
Copy link
Contributor

belkadan commented Dec 8, 2017

Oh, I misread the example. I guess this does make sense.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
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 regression swift 4.0
Projects
None yet
Development

No branches or pull requests

4 participants