@property - take it behind the woodshed and shoot it?

[kenji hara]

2013/1/25 Jonathan M Davis <jmdavisProg at gmx.com>

> On Friday, January 25, 2013 10:15:09 kenji hara wrote:
> > 1. Optional parentheses for normal functions should work shallowly IMO.
> > 2. Optional parentheses for property functions should not work. Applying
> ()
> > for property function name always applied to its returned value.
> >
> > #1 is a ratification of current behavior. It allows the combination of
> UFCS
> > and removing redundant ()s.
> > #2 is a breaking change. If we need it, community consent is required.
>
> I'd say that we should do both. It's ridiculous to accept parens on
> property
> functions, since the whole point is that they be used as if they were
> variables. They're _supposed_ to be illegal (though -property doesn't check
> for it right now like it's supposed to - it only checks whether parens are
> used on non-property functions). So, I don't think that there's any
> question
> that #2 needs to happen with @property (unless Walter's horrid plan gets
> put
> into effect and we lose @property entirely). And #1 seems reasonable
> enough.


Two months ago, I've tried to implement the rule and posted an experimental
pull request.
https://github.com/D-Programming-Language/dmd/pull/1311

>From that experience, we still need to define some behaviors of corner
cases, even if the rule is applied.

One of them is getting an address of property function which returns ref.

@property ref int foo();
auto x = &foo;   // x is a function pointer, or an address of returned
value?

This is the most sensible problem.
(a) If typeof(x) should be a function pointer, we need to use a utility
function to get int*.

   ref identity(T)(ref T t) { return t; }
   int* p1 = &(identity(foo));
      // foo is evaluated to ref int in function argument,
      // and identity gets through the reference.
   int* p1 = &foo.identity;
      // with UFCS, parentheses can be removed.

   This is a real issue. In phobos, the ref-ness of front property is
actually checked in std.range.moveFront.

(b) If typeof(x) should be a int*, we will lose the way to getting a
function pointer of foo.
   That is more serious than (a). If we adopt this rule, we will *really*
get lost the way to distinguish property functions and raw data fields.
(Note that: In current typeof(foo) already returns int. So AddressExp is
only one way to getting (normal|property) function information by its
type.) From the view of meta-programming, I think this makes a serious flaw.

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