> On Jun 23, 2016, at 2:08 PM, Andrew Trick <[email protected]> wrote:
>
>>
>> On Jun 23, 2016, at 2:06 PM, Slava Pestov <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>>> On Jun 23, 2016, at 2:02 PM, Andrew Trick <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>>
>>>> On Jun 23, 2016, at 1:48 PM, Slava Pestov <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>>
>>>>> On Jun 23, 2016, at 1:46 PM, Andrew Trick <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>>
>>>>>> On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution
>>>>>> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
