@property with opCall

[Calvin P]

On Monday, 9 March 2020 at 12:14:06 UTC, Adam D. Ruppe wrote:
> Here's a wiki page referencing one of the 2013 discussions 
> https://wiki.dlang.org/Property_Discussion_Wrap-up
>
> though i'll note the thing is older than that.
>
> What especially drove me nuts is people would so often say 
> "property *syntax*" instead of "property semantics" - everyone 
> would go on and on and on about banning optional parenthesis 
> which should be a totally unrelated discussion when we should 
> have been talking about the semantic question and focusing on 
> the case you discovered - the case that actually matters.


Thanks for reply.

after read the wiki, I am try answer some question.

>  Some people find it difficult to decide if something is a 
> property or a function

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

This can be fixed with a new __traits. and should allow get 
getter/setter functions.


> Some people think the additional @property attribute clutters 
> the source code

I think it made code more readable.

> Can we get a reference to the property? What does &x.property_ 
> mean?

this should be decide base the Getter function attribute,  ref 
function should allow get reference.   ref scope function allow 
get scope ref.

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

I think setter should force return void,   typeof(@property) 
should return getter return type, if no getter should return void.

> What does x.property_++ do?

this should only allow for ref getter with a setter.

> Is returning ref values from the getter OK?

  returning ref values from getter should be allowed.

I find one nice use case will be create a scope ref @property 
base on pointer filed.

struct A {
      B* _ptr;
     @property ref auto b() return scope
     {
         return *_ptr;
     }
}


> Is taking ref values in the setter OK?

I think no harm to allow this.

> UCFS and @property

If can not avoid conflict with UCFS, we can force @property only 
work for class|struct instance method function.

> How many parameters are allowed for property functions?

limit to 1 parameter.  use backtrace for caller position.

> Are templated properties allowed?

I think better not allow templated properties to keep it simple.

> Ambiguous / complicated if a function returns a delegate or 
> similar (solvable with special case rules)
> Complicates semantics for human reader of the code (see 
> comments about readability in "How those are (not!) related")

I can not answer this.  but I think a simple rule can be apply to 
@property:

When there is conflict,  treat it like field, not function.

base on this rule, I think getter function should be @nogc, no 
memory alloc.