[SR-14096] KeyPath when used as a multi-argument function type

[swift-ci]

Previous ID	SR-14096
Radar	rdar://problem/73600325
Original Reporter	artdivin (JIRA User)
Type	Bug
Status	Resolved
Resolution	Done

Attachment: Download

Environment

Swift 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)

Xcode 12.4 (12D4e)

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	artdivin (JIRA)
Priority	Medium

md5: 23293c02146f4ec64ff505bd8d184b25

Issue Description:

Hello!

I have found an undefined behaviour when compiler doesn't generate correct error messages, i.e. compilation succeeds if the type is omitted, but when the type is specified the compilation error is generated correctly.

See cases #2 and #3 in the attached screenshot.

I will add textual representation into the description as well:

import Foundation


extension String {
    
    var filterOut : (Self) throws -> Bool {
        { $0.contains("a") }
    }
    
    var myLocalizedCompared : (Self, Self) throws -> Bool {
        {
            $0.localizedStandardCompare($1) == .orderedAscending
        }
    }
    
}


var unsorted : [String] = [ "asd", "bcd", "def" ]


// 1. compiles, provides output "asd"
print(unsorted.filter { $0.contains("a") })


// 2. compiles, provides empty output
print(unsorted.filter(\.filterOut))


// 3. error: Cannot convert value of type 'KeyPath<String, (String) throws -> Bool>'
// to expected argument type '(String) throws -> Bool'
//print(unsorted.filter(\String.filterOut))


// 4. compiles: however, filter closure signature: (T) throws -> Bool
// and we are passing (T, T) throws -> Bool
// output is empty
print(unsorted.filter(\.myLocalizedCompared))


// 5. error: Cannot convert key path into
// a multi-argument function type '(String, String) throws -> Bool'
//unsorted.sort(by: \.myLocalizedCompared)

[typesanitizer]

@swift-ci create

[xedin]

luciano (JIRA User) You might be interested to take a look at #3 here, #4 I'd say is unfortunately not-to-be-fixed without risking source compatibility impact since this is just a tuple splat behavior, curtesy of pre SE-0110 Swift, where `T` would be bound to `(T, T)` passed as an argument.

[LucianoPAlmeida]

Sure! Thanks for the ping @xedin =]

[LucianoPAlmeida]

For what I understand #3 should definitely fail, so it would be just the case of providing a better diagnostic. Still didn't look but #2 seems a bit curious in what type is getting inferred for Root in order for this to compile ... I'll take a look

[LucianoPAlmeida]

Yeah, in an assert build #2 crashes on assertion
Assertion failed: (!componentTy || componentTy->hasUnresolvedType() || componentTy->getWithoutSpecifierType()->isEqual(leafTy)), function visitKeyPathExpr, file <path>/swift/lib/Sema/CSApply.cpp, line 4765.

[LucianoPAlmeida]

The problem for the #2 case is that type checker don't detect that for the of key path value (Self) throws -> Bool doesn't match the expected contextual function result type Bool.
Inference for key paths still have some issues that we discussed some time ago in SR-12390, but I'm not sure if this have something to do with this but could possible be related.
As far as my understanding #2 should produce the same diagnostic as #3 (or maybe a improvement on the wording making more clear that user is trying to use key path as function but the inferred key path value don't match expected function result type)

[xedin]

@LucianoPAlmeida I think #2 and #3 should type-check because they are equivalent to:

var unsorted : [String] = [ "asd", "bcd", "def" ]

var fn: (String) -> Bool = { $0.contains("a") }
print(unsorted.filter(fn))

It seems to be the reason why they don't is because `Self` is misinterpreted.

[LucianoPAlmeida]

Ah that makes sense, but the same behavior also happens if `filterOut` is declared as explicit as`String`

var filterOut : (String) throws -> Bool { { $0.contains("a") } }

My reasoning in thinking that it could be correct diagnose #2 as a mismatch the same way #3, was that based on key path as functions, #3
should be equivalent to

`_ = unsorted.filter({ $0[keyPath: \String.filterOut] })` 

where the result of key path application is a unapplied function type `(String) -> Bool` that indeed doesn't match the expected return type `Bool`

[xedin]

Ah yes, looks like I misunderstand what SE-0249 was all about - it's supposed to be possible to convert keypath to a function that accepts a base and returns a value of member type referenced by a key path, by that logic `.filterOut` is converted into `(String) -> (Self) throws -> Bool` when used as `filter(.filterOut)`. I agree that both #2 and #3 should produce identical errors.

[LucianoPAlmeida]

Awesome, I still didn't look to deep into it but I'm wondering if the cause for the solver can't detect the mismatch for #2 has something related to what we discussed some time ago in SR-12390 ... I'll take a look soon =]

[LucianoPAlmeida]

Hey @xedin, sorry this is in progress for a while but in fact I haven't be able to really work on it, been in a bit of struggle with other things... but will try to pick this up again this week =]

[xedin]

@LucianoPAlmeida No worries! Take your time.

[xedin]

Fixed by #36531 artdivin (JIRA User) Please use next available main branch snapshot to verify and close.