> On Mar 16, 2016, at 9:53 PM, Douglas Gregor via swift-evolution > <[email protected]> wrote: > >> >> On Mar 16, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution >> <[email protected]> wrote: >> >>> • What is your evaluation of the proposal? >> >> Overall in favor. >> >> I don't like the getter syntax: >> >> float Point3DGetRadius(Point3D point) >> __attribute__((swift_name("getter:Point3D.radius(self:)"))); >> >> I think we would be better off thinking of this instead as adding an >> accessor to a property, perhaps with a syntax along these lines: >> >> float Point3DGetRadius(Point3D point) >> __attribute__((swift_name("Point3D.radius.get(self:)"))); >> >> However, talking about operations-associated-with-a-property seems to be a >> common theme with the behaviors proposal; you may want to think about a >> syntax that could be used for both of them (and perhaps in demangling and >> diagnostics as well). > > FWIW, the “getter:” and “setter:” syntax was borrowed from the discussion of > extending #selector to work with getters and setters of properties. Also, > Point3D.radius.get could be a badly-named function “get” in a badly-named > type “Point3D.radius” ;) > >> I also find it odd that this proposal doesn't address subscripts. > > Yeah. It should probably be a part of the proposal for completeness. > >> >> I assume that, on types imported as value types, Swift treats operations >> whose self parameter is a (non-const) pointer to the type as mutating and >> others as nonmutating. (This is not explicitly stated in the proposal, >> though.) > > That’s correct. It’s in the implementation but not the proposal. > >> However, it's not clear how Swift makes that initial determination of >> whether a type should be imported as a value type or a reference type. > > That’s actually orthogonal to this proposal. However, right now you have C > enums and structs mapping to value types, CF types mapping to reference > types, and ObjC classes and protocols mapping to reference types. > >> Has this proposal's use against libdispatch been evaluated? I would love to >> see `dispatch_async(_:_:)` become `dispatch_queue.async(function:)`. > > IIRC, the heuristics didn’t work so well, but it should be possible to > swift_name lib dispatch.
swift_name is very useful for libDispatch and is showing success, so the manual annotation portion of this proposal fits very well. The inference heuristics are currently not tuned well for libDispatch, and adjusting them is probably future work. In the mean time, manual annotation in the C API is not too burdensome and a definite improvement over overlays. > > - Doug > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
