DIP23 draft: Fixing properties redux

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun Feb 3 08:11:05 PST 2013


On 2/3/13 5:14 AM, Johannes Pfau wrote:
> "If a function returns a reference, then assignment through the
> paren-less call should work: "
>
> This is the only part where I would disagree. Why is this special rule
> necessary if we have full @property support? I think this would still
> allow too many false positives.

(As a note, this is the current behavior.)

The way I see it is this is a natural consequence of optional parens. 
The name of a function without a "&" prepended or a "()" after it will 
invoke the function, and that's that.

> One important aspect that this proposal doesn't cover yet is whether we
> want to allow "semantic rewriting" for properties:
> ----
> Struct a;
> a.property++; //would this be legal?
> ----

It's dangerous to get too clever about that. Anyhow, such rewrites are 
possible:

++a.p ----> { auto v = a.p; ++v; a.p = v; return v; }()
a.p++ ----> { auto v = a.p; ++a.p; return v; }()

and so on.

> for other corner cases this list is a good start:
> http://wiki.dlang.org/Property_Discussion_Wrap-up#Implementation_concerns
>
> * Can we get a reference to the property? What does
>    &x.property mean?

We need to add this to the proposal. There are two schools of thought here:

1. Make properties emulate regular variables as much as possible. In 
that case &a.p is the same as &(a.p), i.e. it applies to the returned 
value. (One counter-argument here is that properties should seldom 
return a reference because that breaks encapsulation.)

2. Allow people to do whatever they need to do without much aggravation. 
In that case &a.p obeys the normal rules of taking a method's address, 
and &(a.p) applies to the returned value.

I favor (2) and put it in http://wiki.dlang.org/DIP23. Will talk to Walter.

> * How can we get the getter / setter functions? Do we need to get those?

Per (2) above there is no need for special provisions.

> * What is the type of the property? Return type, setter function type
>    or getter function type? How to get the other types?

typeof(r.front) is the return type of the property, typeof(&(r.front)) 
is the type of a pointer to the return type of the property where 
applicable, and typeof(&r.front) is the (possibly ambiguous) address of 
the method. (To disambiguate one would use the appropriate receiver type.)

> * What does x.property++ do?
>    ([http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property#Semanticrewritingofproperties
>    Semantic rewriting])

Added to http://wiki.dlang.org/DIP23.

> * Is returning ref values from the getter OK?

I see no reason to disallow it at the language level.

> * Is taking ref values in the setter OK?

How do you mean that?

> * Should all properties be nothrow? pure? getter const?
> ** Probably better as a rule for style guide.

No restriction at language level.

> * Are UFCS properties possible? How do they work exactly?
> * How do you disambiguate property functions when they're free
>    functions which conflict?

I think it would be best to simply disallow parameterless module-level 
properties.

// at top level
@property int foo(); // error
@property int goo(int); // fine, assume a getter for int

> ** Normal UFCS functions can be force
>    called by using their fully qualified name. That's not possible for
>    properties if function call syntax is disallowed?

Correct. Writing @property buys the writer into a constrained universe.

> * How many parameters are allowed for property functions?

One or two at top level, zero or one at member level.

> ** Are default parameters allowed?
> ** Especially consider the example about __FILE__ and __LINE__

I'd say no. Just keep it simple and focused on the goal.

> * Are templated properties allowed?
> ** The access syntax for properties doesn't allow providing types

No. Templated member variables are not allowed either.


Andrei


More information about the Digitalmars-d mailing list