> On Jun 23, 2016, at 2:06 PM, Slava Pestov <[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.
-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
