On Wed, Dec 12, 2018 at 02:10:31PM -0700, Jonathan M Davis via Digitalmars-d-announce wrote: > On Wednesday, December 12, 2018 6:03:39 AM MST Kagamin via Digitalmars-d- > announce wrote: [...] > > Imagine you have void delegate() prop() and use the property > > without parentheses everywhere then suddenly m.prop() doesn't > > call the delegate. So it's mostly for getters and should be used > > only in edge cases, most code should be fine with optional parens. > > Except that @property does not currently have any effect on this. The > delegate case (or really, the case of callables in general) is one > argument for keeping @property for using in that particular corner > case, since without it, having property functions that return > callables simply doesn't work, but @property has never been made to > actually handle that case, so having property functions that return > callables has never worked in D. It's certainly been discussed before, > but the implementation has never been changed to make it work.
Yep. Basically, @property as currently implemented is useless, and I've stopped bothering with it except where Phobos requires it. > If/when we finally rework @property, that use case would be the number > one reason to not simply get rid of @property, but until then, it > doesn't actually fix that use case. As things stand, @property > basically just serves as documentation of intent for the API and as a > way to screw up type introspection by having the compiler lie about > the type of the property. [...] Haha yeah, currently @property confers no real benefits and only comes with bad (and probably unexpected) side-effects. More confirmation that it's a waste of time and not worth my attention. If the delegate property thing is the only real use case for @property, it seems quite out-of-proportion that an entire @-identifier in the language is dedicated just for this purpose. One would've thought D ought to be better designed than this... T -- Gone Chopin. Bach in a minuet.
