[swift-evolution] [Pitch] Make the formal type of 'self' consistent in class methods
L. Mihalkovic
laurent.mihalkovic at gmail.com
Thu Jun 23 23:09:15 CDT 2016
Quick (semi) related question: any particular reason for .Type to be a contextual kwd rather than defined on a protocol? (No concrete def for metatypes?)
Regards
LM
(From mobile)
> On Jun 23, 2016, at 11:02 PM, Andrew Trick via swift-evolution <swift-evolution at swift.org> wrote:
>
>
>>> On Jun 23, 2016, at 1:48 PM, Slava Pestov <spestov at apple.com> wrote:
>>>
>>>
>>>> On Jun 23, 2016, at 1:46 PM, Andrew Trick <atrick at apple.com> wrote:
>>>>
>>>>
>>>> On Jun 23, 2016, at 12:53 PM, Slava Pestov via swift-evolution <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 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160624/1366102f/attachment.html>
More information about the swift-evolution
mailing list