On Jan 22, 2013, at 11:25 AM, John McCall <rjmcc...@apple.com> wrote:
> On Jan 22, 2013, at 11:03 AM, Matt Neuburg <m...@tidbits.com> 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 = m...@tidbits.com, 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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
