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 11:25:47 -0800
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.
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