Blog post: What D got wrong

Jonathan M Davis newsgroup.d at jmdavisprog.com
Wed Dec 12 21:10:31 UTC 2018


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






More information about the Digitalmars-d-announce mailing list