@property

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, December 08, 2016 22:11:22 ArturG via Digitalmars-d-learn 
wrote:
> On Thursday, 8 December 2016 at 16:54:57 UTC, Adam D. Ruppe wrote:
> > On Thursday, 8 December 2016 at 16:53:13 UTC, Satoshi wrote:
> >> is there any advantage of marking function as @property??
> >
> > Not really. I think it just changes the meaning of
> > typeof(thatfunc) but otherwise it does nothing.
> >
> > However, if you use it in a base class, you must also use it
> > when overriding the function.
>
> it does when you add it to for example a struct with alias opCall
> this.
> reported it as a bug
> https://issues.dlang.org/show_bug.cgi?id=16951
>
> but seems to be addressed by https://wiki.dlang.org/DIP23

Except that it's not really a bug. It's a design flaw in the original
solution for properties which gave us optional parens. And since @property
has never really been implemented to properly _do_ much of anything, it
doesn't actually fix the problem. While it's a nice idea in concept,
@property was half-baked from the beginning, and it's never actually done
anything useful except act as documentation. So, as it stands, @property
doesn't matter for anything like this. It's just that we would need to
actually implement something with it to solve that particular problem (DIP23
being one proposal to do so). And as it stands, property functions for
callables simply don't work like a variable would, defeating the purpose of
making them properties.

It would be very nice if we got a DIP that was approved which solved this,
but @property is not a topic that much of anyone wants to discuss at this
point. There's never really been agreement on how properties should be
handled in D, and everyone is sick of discussing it. And we've lived with
this flaw with callables and properties for years now. So, I think that it
would be pretty hard to get a DIP past Walter and Andrei, much as we really
should clean this @property mess up.

- Jonathan M Davis