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