> On Mar 17, 2016, at 11:45 AM, Michael Ilseman via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Mar 16, 2016, at 9:53 PM, Douglas Gregor via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>>
>>> On Mar 16, 2016, at 4:48 PM, Brent Royal-Gordon via swift-evolution
>>> <[email protected] <mailto:[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.
>>
For subscripts, I have 3 alternatives below to consider, ordered in my personal
list of preference. Which seems to make the most sense?
1.
// Import as subscript
float Point3DGetPointAtIndex(int idx, Point3D point)
__attribute__((swift_name("getter:subscript(index:self:)")))
void Point3DSetPointAtIndex(int idx, Point3D point, float val)
__attribute__((swift_name("getter:subscript(index:self:_:)")))
2.
// Import as subscript
float Point3DGetPointAtIndex(int idx, Point3D point)
__attribute__((swift_name("getter:subscript(_:self:)")))
void Point3DSetPointAtIndex(int idx, Point3D point, float val)
__attribute__((swift_name("getter:subscript(_:self:newValue:)")))
3.
// Import as subscript
float Point3DGetPointAtIndex(int idx, Point3D point)
__attribute__((swift_name("getter:subscript(index:self:)")))
void Point3DSetPointAtIndex(int idx, Point3D point, float val)
__attribute__((swift_name("getter:subscript(index:self:newValue:)")))
>>>
>>> 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] <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
