[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