Re: object.struct.element as lvalue
Re: object.struct.element as lvalue
- Subject: Re: object.struct.element as lvalue
- From: Matt Neuburg <email@hidden>
- Date: Tue, 22 Jan 2013 11:59:31 -0800
On Jan 22, 2013, at 11:25 AM, John McCall <email@hidden> wrote:
> On Jan 22, 2013, at 11:03 AM, Matt Neuburg <email@hidden> wrote:
>> We have dot-syntax for accessors, and we have dot-syntax for struct elements, and we can chain them, but not as an lvalue. It is legal to say
>>
>> x = object.struct.element
>>
>> and
>>
>> object.struct = f
>>
>> and
>>
>> struct.element = x
>>
>> but not
>>
>> object.struct.element = x
>>
>> I suppose this is because you can't use the very same accessor as a getter and a setter simultaneously, but really it's quite obvious what this means: it means means
>>
>> temp = object.struct
>> temp.element = x
>> object.struct = temp
>>
>> So *why* can't the compiler just allow it to mean that, instead of making me write it all out by hand? There's no ambiguity as far as I can tell. The ARC compiler is supplying plenty of code behind the scenes, including temporary variables, so surely it wouldn't be onerous to do the same sort of thing here. m.
>
> You are correct that it is absolutely implementable with these semantics. I think we have bugs open on it already, but you can "vote" by filing a new one.
>
> One obvious concern with supporting this is the fear that somebody's going to write:
> obj.dimensions.x = x;
> obj.dimensions.y = y;
> obj.dimensions.width = width;
> obj.dimensions.height = height;
> which is, yes, admittedly convenient, but which is massively less efficient than the alternative:
> obj.dimensions = (struct Dimensions) { x, y, width, height };
> both because it does eight message sends instead of one and because it's likely to cause four separate notifications, three of them totally unnecessary, instead of one.
>
I did think of that - though it wouldn't surprise me if the compiler were so smart that it could fix even that. :)
I'll file a bug; thanks. Would this be a bugreporter bug or do I need to talk to the clang people?
The real reason for my asking this question is that I'm having trouble justifying to the naive reader exactly *why* object.struct.element can't be an lvalue. At the moment, my proposed "you can't use the very same accessor as a getter and a setter simultaneously" is the best I've come up with. m.
--
matt neuburg, phd = email@hidden, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden