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