Re: object.struct.element as lvalue
Re: object.struct.element as lvalue
- Subject: Re: object.struct.element as lvalue
- From: John McCall <email@hidden>
- Date: Tue, 22 Jan 2013 14:51:18 -0800
On Jan 22, 2013, at 11:59 AM, Matt Neuburg <email@hidden> wrote:
> 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. :)
To optimize this, we'd need some new and very strong language guarantees about what property accessors can actually do — essentially, that they're really just decorators on loads and stores to some logical object somewhere. I can promise that there's a lot of existing code that wouldn't satisfy those rules.
In general, the compiler has to treat any message send, including those done as part of property accesses, as a hard abstraction barrier, even when we can see the class's implementation of the method. That's because (1) we can't prove the non-existence of formal subclasses, and even if we could, (2) method and class swizzling are part of the language model. So we can't ever devirtualize an ObjC message send or treat it as anything except a hard abstraction barrier, unless it's somehow annotated on the method declaration.
> I'll file a bug; thanks. Would this be a bugreporter bug or do I need to talk to the clang people?
You're requesting an enhancement to the Objective-C language as implemented in Apple products; you should file it with bugreporter.
> 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.
Heh. And even that is actually incorrect, because you can do things like x.count += 6, which is translated as [x setCount: [x count] + 6] (except only evaluating 'x' once).
I would say that object.struct is a special kind of l-value that's limited in how it can be used. You can use it as the l-value operand of a simple assignment, compound assignment, increment, or decrement operator, but any other use causes it to be converted to an r-value.
John.
_______________________________________________
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