[SR-1051] Implement SE-0042 - Flattening the function type of unapplied method references

[lattner]

Previous ID	SR-1051
Radar	rdar://problem/25878529
Original Reporter	@lattner
Type	Improvement
Status	In Progress
Resolution

Additional Detail from JIRA

Votes	1
Component/s	Compiler
Labels	Improvement
Assignee	jaspa (JIRA)
Priority	Medium

md5: c0489b3d664c0051f324983f13c46c29

Issue Description:

SE-0042 has been accepted:
https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md

We need an implementation now!

[swift-ci]

Comment by Janek Spaderna (JIRA)

#3836

[benrimmington]

@jckarter or @slavapestov, does this bug need to be added to the ABI Dashboard?

[jckarter]

It doesn't affect ABI, it's only a source-level behavior change.

[slavapestov]

This change would not affect ABI, but it does clearly have source compatibility impact so if we ever implement this proposal it would need to be staged in with a -swift-version flag.

However I think at this point it would have to go through review again and it would be unlikely to be accepted without changes. One option is to deprecate the old unapplied method reference syntax, and instead use keypath syntax, for example \Foo.bar, which would have the new type.

[benrimmington]

Thanks, there was a suggestion to retool thunks to have the new uncurried type by default, so I thought it might affect ABI.

[jckarter]

Those kinds of thunks generally have private linkage, since they can be generated at will by any module that needs them.

[sveinhal]

What's the status on this? Has it been abandoned?

[DevAndArtist]

@slavapestov even though this is super old, the idea going the key-path way seems good, but in some cases it is not possible because key-paths require hashability, which means that function parameter types and the result type also would need to be hashable.

[jckarter]

Key path literals don't need to be constrained to hashability in function context. Functions aren't hashable.

[DevAndArtist]

Ah, then you are saying that the key path literal will be transformed into a closure just like the recently accepted proposal? Otherwise I‘m not sure I follow.

[slavapestov]

> Ah, then you are saying that the key path literal will be transformed into a closure just like the recently accepted proposal?

Yes, that would be the idea. We should also transform unapplied method references to closures too, and remove all the SILGen support for "curry thunks".