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

Douglas Gregor dgregor at apple.com
Wed Mar 16 23:53:04 CDT 2016

> 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 libdispatch.

	- Doug

More information about the swift-evolution mailing list