> On Apr 6, 2017, at 1:06 PM, John McCall <rjmcc...@apple.com> wrote: > >> On Apr 6, 2017, at 1:41 PM, Matthew Johnson <matt...@anandabits.com >> <mailto:matt...@anandabits.com>> wrote: >>> On Apr 6, 2017, at 12:32 PM, John McCall <rjmcc...@apple.com >>> <mailto:rjmcc...@apple.com>> wrote: >>> >>>> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> The rationale for using the same syntax is that a KeyPath is an unapplied >>>>> property/subscript access. Even the multi-segment part of it isn't >>>>> necessarily dissimilar: I don't think it would be unreasonable to imagine >>>>> that \Foo.someMethod.someOtherMethod could work*, that'd just be function >>>>> composition after all. >>>>> >>>>> KeyPath : Properties/Subscripts :: Functions with a self argument : >>>>> Methods >>>>> >>>>> David >>>>> >>>>> *not proposing this, haven't thought carefully about whether there are >>>>> edge cases I'm missing here, but I think the analogy holds >>>> >>>> I alluded to this kind of thing in the earlier threads. It would be very >>>> cool to see this explored in the future. >>>> >>>> I really like the latest draft and am eagerly anticipating Smart KeyPaths >>>> being implemented. Thank you for listening to feedback from the community! >>>> >>>> One possible future direction I have been wondering about is whether it >>>> might be interesting to expose an anonymous type for each distinct key >>>> path which would have static members for getting (and setting if mutable) >>>> the value. The types would inherit from the most specific matching key >>>> path type included in this proposal. This would allow us pass key paths >>>> statically using the type system and therefore not requiring any runtime >>>> overhead. >>>> >>>> I have experimented with this approach in some of my own code and it looks >>>> like it would be a very promising approach aside from the boilerplate >>>> required to write these types manually. I have abandoned this approach >>>> for now because of the boilerplate and because the syntactic sugar of the >>>> key path shorthand in this proposal is too attractive to pass up. I would >>>> love to explore it again in the future if key paths were to support this >>>> approach. >>> >>> Our generics system does not require generic code to be de-genericized >>> ("instantiated" in C++ terminology, "monomorphized" in Rust, etc.) in order >>> to be run. The generic code for applying a value of an unknown key-path >>> type would look exactly like the non-generic code for applying a dynamic >>> key-path type. To get a runtime benefit, the compiler would have to >>> de-genericize all the code between the function that formed the concrete >>> key path and the function that applied it. If the compiler can do that, it >>> can also specialize that code for a known key path argument, the same way >>> that it can specialize a function for a known function argument. So >>> there's no point. >> >> Thanks for the reply John. There may not be any additional optimization >> opportunities in terms of code generation when using the key path but >> wouldn’t it save on storage and reference counting related to key path value? > > If you're specializing all the way down, any sort of boxing should be > possible to eliminate as well. > > If you mean in unspecialized code, well, I'm not entirely sure what > representation Joe is using, but I would assume that the fast path — where a > key path doesn't capture anything — does not require any allocation. In that > sense, there's a strong parallel with how we represent functions: yes, > avoiding an extra allocation would be nice, but if you're willing to accept > an occasional allocation in more complex cases, there are also a lot of > benefits from being able to always give the type a concrete, fixed-size > representation.
Key paths in this proposal are classes which require storage of the pointer as well as reference counting unless there is special of key path values. Is something like that planned? I could imagine some kind of tagged pointer might be possible but I can’t imagine how you would eliminate the need to store a word. It’s not that much overhead but it would still be nice to be able to avoid it when all we’re doing is passing a stateless function reference. > >> As a secondary question, wouldn’t this be similar to the difference between >> generics and existentials? In theory the same optimizations could be >> applied but in practice they are not always right now. Is the plan to >> eventually put existentials on equal footing in terms of optimization? > > Eventually, yes, I think that's something we'd like make sure we can do. > > John. > >> >>> >>> John. >>> >>>> >>>> Matthew >>>> >>>>> >>>>>> On Apr 5, 2017, at 5:16 PM, Patrick Smith via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>> >>>>>> I too find the backslash odd, as it’s usually of course used to escape >>>>>> something. >>>>>> >>>>>> What about three periods? >>>>>> >>>>>> let firstFriendsNameKeyPath = Person...friends[0].name >>>>>> print(luke[keyPath: ...friends[0].name]) >>>>>> >>>>>> >>>>>> I also find wanting to use the same syntax for unapplied methods >>>>>> strange, as they would product two totally different things: one a key >>>>>> path value, the other a function. >>>>>> >>>>>> Patrick >>>>>> On Thu, 6 Apr 2017 at 10:00 am, Douglas Gregor via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>>> On Apr 5, 2017, at 4:55 PM, Colin Barrett <co...@springsandstruts.com >>>>>>> <mailto:co...@springsandstruts.com>> wrote: >>>>>>> >>>>>>> Is the choice of backslash up for review? I think another operator, >>>>>> >>>>>> We talked through basically everything on the keyboard, and there really >>>>>> aren’t other options that don’t stomp on existing behavior. >>>>>> >>>>>>> perhaps backtick (`), would work better. >>>>>> >>>>>> Backtick (`) is already taken for escaping identifiers, e.g., >>>>>> >>>>>> var `func` = { /* some code */ } >>>>>> >>>>>> - Doug >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
