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

Jordan Rose jordan_rose at apple.com
Tue Mar 22 20:03:04 CDT 2016


> On Mar 22, 2016, at 17:21, Michael Ilseman via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On Mar 17, 2016, at 11:45 AM, Michael Ilseman via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Mar 16, 2016, at 9:53 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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.
>>> 
> 
> 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:)")))
> 

Do any of these allow you to put labels on the imported subscript indices? I would expect the declaration in #3 to come through as (the completely legal Swift code):

subscript(index index: CInt) -> CFloat

which you would then use as

myPoint[index: 0]

(Clarification for anyone following along: it's important to be able to distinguish the index parameter from the new value, which we wouldn't want to hardcode the order of. We also wouldn't want to have to look up the getter to figure it out.)

I'd rather not claim 'newValue' as a magic name, but I don't see a good alternative. So my vote is for #2.

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160322/a010f9fd/attachment.html>


More information about the swift-evolution mailing list