[swift-evolution] [swift-evolution-announce] [Review] SE-0044 Import as Member

[Michael Ilseman]

> On Mar 16, 2016, at 9:53 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Mar 16, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> 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
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160317/0db07e8e/attachment.html>