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