DIPS

Property

Everyone agrees that @property doesn't work well right now. People disagree what's the actual problem with @property. Some people were arguing to remove @property completely. It's not clear if those were advertising making normal functions callable like @properties or removing @property without replacement.

Why @property

As there were suggestions of removing @property completely we should think about what problem @properties should solve:

Properties are a replacement for fields

Unlike fields, they are polymorphic

As they are supposed to be used as fields, they are for data access and nothing else

They are especially not there to make function calls without parentheses. This is a different issue. To the developer properties are not functions, they're enhanced fields. The fact that they are implemented as functions is a implementation detail.

D as a systems programming language should still provide a way to detect if something is a property and to get the getter/setter. This shouldn't be visible in normal usage.

Now consider how to implement the above if properties were completely removed, as proposed. The D1 solution allowed assignment syntax for normal functions. So the above example could work exactly the same way, but @property wouldn't be used. This is a poor solution for properties as it allows to write nonsensical code:

voiduse(){writeln=42;//would call writeln(42);writeln+=1;//How would this even be implemented without @property?}

Note that this is in no way related to the optional parentheses discussion: You can have parentheses, a @property implementation and still disallow code like writeln = 42;

Breakage when removing @property

//In druntime's object_.d AssociativeArray has:@propertysize_tlength(){return_aaLen(p);}//that can't be rewritten as a field, so without @property it must be a function//Right now:assert(is(typeof([int][int].length)==size_t);//Without @propertyassert(is(typeof([int][int].length)==size_tfunction());

Cons

(Please do not add implementation issues, only conceptual issues)

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

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

Property declaration syntax

Some new syntaxes have been proposed for property declaration:

Could make declaring properties less verbose

Would break lots of code

Could be done without breakage with new attributes (@prop), but that's ugly

There's no need for a new syntax. Although the current syntax is verbose, it does not have real issues. The issues happen when using properties, not when declaring them.

The allowed function prototypes (ref) should be reviewed though and it should be made clear how they interact:

@propertyrefintprop();@propertyintprop();@propertyvoidprop(intvalue);@propertyintprop(intvalue);@propertyvoidprop(refintvalue);//not as problematic

Implementation concerns

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

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

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

Code examples

__LINE__ / __FILE__

Proposals

Optional parentheses

Pro

UFCS code looks nicer:

autoyesterday=2.days.ago;some!(e1).ufcs!(e2).chaining!(e3)//instead ofsome!(e1)().ufcs!(e2)().chaining!(e3)()//We need a real world UFCS case demonstrating this.//There are real world examples - even in that discussion thread - but I cant find them ;-)

Extra note

The same way "." can dereference pointer, it is unambiguous to automatically call functions on ".". This shortcut is unambiguous (even if some people may find it confusing when reading code).

// Only the last () is necessary in that case.some!(e1).ufcs!(e2).chaining!(e3)()

Cons

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")

How those are (not!) related to properties

Both properties and optional parentheses are basically orthogonal. It's possible to have both, have none, and have any mix of those.

The small issue where they interfere is code readability:

If optional parentheses are disallowed, it's easy to see that

autovar=newsomeClass();autox=var.something;

will always be either a field access or a property call. But according to property definition (as used by C# and other languages), properties should behave like fields (i.e. constant complexity, no side-effects,...). Therefore without optional parentheses it's possible to see if an access is actually a potentially heavy weight function call or data / property access.

Except from this, @property and optional parentheses are orthogonal.

Unified test suite

Aims to provide one source file that provides all use cases that work with current lax rules. Any proposal should give clear answer, which of them are allowed and how those should work.