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.
