[swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods

[Slava Pestov]

> On Jun 23, 2016, at 2:08 PM, Andrew Trick <atrick at apple.com> wrote:
> 
>> 
>> On Jun 23, 2016, at 2:06 PM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>> 
>> 
>>> On Jun 23, 2016, at 2:02 PM, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote:
>>> 
>>>> 
>>>> On Jun 23, 2016, at 1:48 PM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On Jun 23, 2016, at 1:46 PM, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>> The proposal is to change the type of self to always be Self, which can be thought of as a special generic type parameter bound to the dynamic type of the instance.
>>>>> 
>>>>> We’re currently specializing functions that take `self` as an argument. I don’t think that will be possible after your proposed change.
>>>>> 
>>>>> - Andy
>>>> 
>>>> I’m not sure what that means. Do you currently punt on certain optimizations if a method returns ‘Self’?
>>>> 
>>>> It should be possible to keep the reified type information around, by passing in a metatype or something for example. Can you give a concrete code snippet demonstrating the optimization and how this change would inhibit it?
>>> 
>>> We bail out of generic specialization, inlining, and function signature specialization when a type substitution contains dynamic self. (hasDynamicSelfTypes). So, yes we currently almost entirely punt on optimization for methods that return Self.
>> 
>> I see. That makes sense.
>> 
>> I think the problem is that if we specialize a top-level function with a substitution involving Self, we have no way to recover what the ‘Self’ type actually is in IRGen. However I think it could be made to work by passing in a metatype for Self, and somehow ensuring we don’t mix up Self from two different contexts...
>> 
>> This is certainly a trickier change than I first imagined, but it would be nice to figure out how to solve this in a principled way so that we can get these optimizations to be more generally applicable. It seems even more surprising, now, if changing the return type of a method inhibits optimizations in a non-obvious way, especially ones that can have a drastic effect on performance.
>> 
>> I think next week I’ll try implementing this proposal behind a staging flag, and play around with the optimizer to see how hard it would be plumb through the relevant type information.
>> 
>> Slava
> 
> Perfect. I didn’t mean to discourage you, just warn you that some benchmarking and optimizer work is also needed.
> 

No worries :) Dynamic ‘Self’ is one of the dark corners of Swift I don’t fully understand — so the proposal is as much about cleaning it up as clarifying my own understanding of the issues.



> -Andy
> 
>> 
>>> 
>>> I don’t have an interesting case to point out. You can look into any trivial example:
>>> 
>>> func foo<T>(_: T) {}
>>> 
>>> func method() {
>>>   foo(self)
>>> }
>>> 
>>> -Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160623/6194499c/attachment.html>