@property needed or not needed?

kenji hara k.hara.pg at gmail.com
Sun Dec 2 18:23:19 PST 2012


I had been trying to advance the phase to the next.
Now, an experimental pull request is here.
https://github.com/D-Programming-Language/dmd/pull/1311

----
This change can distinguish almost usages between property and non-property
syntax

int func() { return 1; }
void func(int n) { }
@property int prop() { return 2; }
@property void prop(int n) { }
void main() {
  // Without -property switch, all lines can compile.
  // With -property switch:
  func();     // OK -> OK
  func(1);    // OK -> OK
  func;       // OK -> OK [*]
  func = 1;   // OK -> NG (fixed!)
  prop();     // OK -> NG (fixed!)
  prop(1);    // OK -> NG (fixed!)
  prop;       // OK -> OK
  prop = 1;   // OK -> OK
}

First exception is [*], keeping the line is necessary to allow UFCS chain
without redundant parentheses (e.g. r.map!(a=>a*2).array). It is acceptable
to me, at least.

----
I also implemented that calling function pointer which returned by property
function.

@property foo(){ return (int n) => n * 2; }
auto n = foo(10);  // `foo` is resolved to property function call in advance
assert(n == 20);

But, we cannot support it immediately, because it will *always* introduce
breaking of existing code.

- If enable always this feature, propfunc() is implicitly translated to
(propfunc())(),
  then much existing correct code without "-property" switch will break.
- If enable this only when -property switch is specified, a code propfunc()
will have
  _two_ meanings. When propfunc returns a function pointer,
  * If -property is on, propfunc() is translated to propfunc()(), then
    call returned function pointer and returns its result.
  * If -property is off, propfunc() is jsut call property function, then
    returns function pointer.

Changing compilation behavior by compile switch is bad.
Then it is the second exception.

----
The third exception is in AddressExpression (&exp).

In current, both &func and &propfunc return their function pointers. Some
peoples argues
that the latter should return an address of the returned value of propfunc
after implementing more property enforcement, but I'm difficult to accept
that.

The root cause is: AddressExpression is just only one built-in feature for
getting an exact type of property function (Note that typeof(propfunc)
returns the type of propfunc result).

If compiler will always translate the code &propfunc to &(propfunc()),
we will lost a way to get an exact type of propfunc, and then
std.traits.FunctionTypeOf will never work for propfunc.

To resolve the issue, I have proposed a small enhancement for
AddressExpression.
http://d.puremagic.com/issues/show_bug.cgi?id=9062

It will distinguish &propfunc and &(propfunc), the former returns a
function poiinter of propfunc, and the latter returns an address of
propfunc result.

The real example about that is here.
https://github.com/D-Programming-Language/phobos/pull/968/files#L0L1136

----
How about that?

Kenji Hara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121203/9b340013/attachment.html>


More information about the Digitalmars-d mailing list