Is the -property compiler flag broken/bad idea?

Diggory diggsey at googlemail.com
Thu Jun 6 03:00:23 PDT 2013


On Thursday, 6 June 2013 at 00:56:22 UTC, Adam D. Ruppe wrote:
> On Thursday, 6 June 2013 at 00:08:31 UTC, Jonathan M Davis 
> wrote:
>> Which is essentially the position of weak property enforcement.
>
> Yes, though I wish we would stop calling it 'enforcement' 
> because nothing actually needs to be especially enforced if we 
> do it right!
>
> @property int foo();
>
> foo(); // error, type int is not callable
>
> @property void delegate() foo();
>
> foo(); // works, calls the returned delegate.
>
>
> This isn't a syntax case in the parser looking at syntax, it is 
> a natural consequence of the @property function call being 
> substituted for its return value.
>
> Similarly btw:
>
> &foo; // error, foo is not an lvalue
>
> because foo here is a returned int or whatever. This isn't 
> directly substitutable for a plain "int foo", but that's ok 
> because one benefit of properties is we get to do things 
> regular members can't, like restrict read or write access like 
> this.
>
> @property ref int foo();
>
> static assert(is(typeof(foo) == int));
> static assert(is(typeof(&foo) == int*));
>
> foo = 10; // ok
>
> that works now because ref int is an lvalue. An @property 
> returning a reference is one case were we should be able to get 
> (almost*) 100% substitution between it and a regular member 
> variable.
>
> * __traits(propertyImplementation, foo) or something like that 
> might still show something different, but if you're using that 
> kind of thing, it is clear that you want special access anyway.
>
>
>
> I've tried to implement this in the compiler before. It seems 
> like it would be a simple case of a semantic rewrite of "foo" 
> into "foo()" iff foo is @property as soon as you see it. But 
> the implementation is hard because of things like setters. foo 
> = 10 should be rewritten into foo(10), but that's easier said 
> than done - it either has to undo the foo->foo() rewrite on the 
> left hand side, then look for the matching setter, or the 
> rewrite has to be moved.... and moving it means duplicating it 
> in all the bazillion places it can be referenced.
>
> So my attempt got 90% to where I wanted pretty easily, but that 
> last 10% is a hell of a bump in the road and I haven't figured 
> it out yet. A working pull request would surely be a big step 
> toward closing this discussion once and for all, I wish I had 
> more free time, I have so  much D I want to hack on!

That would be good - some breakage could be avoided by checking 
if the return type of the property implements the function call 
operator, if it doesn't you could accept the "getter()" syntax 
with only a warning/deprecation message.


More information about the Digitalmars-d-learn mailing list