On Wednesday, December 12, 2018 6:03:39 AM MST Kagamin via Digitalmars-d- announce wrote: > On Tuesday, 11 December 2018 at 12:57:03 UTC, Atila Neves wrote: > > @property is useful for setters. Now, IMHO setters are a code > > stink anyway but sometimes they're the way to go. I have no > > idea what it's supposed to do for getters (nor am I interested > > in learning or retaining that information) and never slap the > > attribute on. > > 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. 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. > >I think there’s a general consensus that @safe, pure and > >immutable should be default. > > I can agree there are at least 5 people holding that firm belief, > but that's hardly a consensus. There are definitely people who want one or more of those attributes as the default, but I very much doubt that it's a consensus. It wouldn't surprise me if @safe or pure by default went over fairly well, but I'm sure that immutable or const by default would be far more controversial, because that's a big shift from what C-derived languages normally do. Personally, I would be very unhappy if it were the default, though I know that there are some folks who would very much like to see const or immutable be the default. > >I’ve lost count now of how many times I’ve had to write @safe > >@nogc pure nothrow const scope return. Really. > > If immutable was default, wouldn't you still need to write const > attribute everywhere, and @nogc, and nothrow? Strings are like > the only relevant immutable data structure (and they are already > immutable), everything else is inherently mutable except for use > cases with genuine need for immutability like a shared cache of > objects. If immutable were the default, then I expect that writing types that worked with immutable would become more common, because it would then be encouraged by the language, but I think that your average type is written to work as mutable (and maybe const), and it's a pretty big shift to write types to be immutable unless you're talking about simple POD types, so if immutable became the default, I expect that mutable (or whatever the modifier to make a type mutable would be) would start getting plastered everywhere. And without the range API being changed, ranges wouldn't work unless you marked them as mutable, making const or immutable by default a bit of a mess for what would now be idiomatic D code (though if the default were changed to const or immutable, we'd probably see the range API be changed to use the classic, functional head/tail list mechanism rather than front and popFront, which could very well be an improvement anyway). - Jonathan M Davis
