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

[Michael Ilseman]

> On Mar 22, 2016, at 6:03 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
>> 
>> On Mar 22, 2016, at 17:21, Michael Ilseman via swift-evolution <swift-evolution at swift.org <mailto: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):
> 

Prior to this, anything that wasn’t “self” would be treated as an argument label. That is, you couldn’t (via current syntax) name an argument label “self”. Now, because subscript’s setter requires two specific parameters in addition to self, we need to special-case another word, either “index” or “newValue” (or both).

I don’t really like any of these solutions. How about changing swift_name’s special label syntax? Something to denote the specialness of self/newValue? Then we could go with option 2.


__attribute__((swift_name("Type.foo(@self:otherParam:")));
__attribute__((swift_name("Type.foo({self}:otherParam:")));
__attribute__((swift_name("Type.foo(<self>:otherParam:")));
__attribute__((swift_name("Type.foo([self]:otherParam:")));
__attribute__((swift_name("Type.foo(`self`:otherParam:")));
__attribute__((swift_name("setter:Type.subscript(`self`:_:`newValue`")));

Any ideas?


> 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/45e0441b/attachment.html>