On Jan 22, 2013, at 11:59 AM, Matt Neuburg <m...@tidbits.com> wrote:
> 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. :)
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 (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
