Beta D 2.069.0-b1

[Jonathan M Davis via Digitalmars-d-announce]

On Saturday, October 10, 2015 02:57:01 Meta via Digitalmars-d-announce wrote:
> On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
> > That's what I meant, weird use-case, at best it's a callback
> > better/setter.
> > I've never written such code, but even if you would, the 2
> > pairs of parens are only a tiny problem for generic code,
> > nothing to warrant the invasive language feature @property is.
>
> I don't know how much metaprogramming-heavy generic code you've
> written, but I can say from first-hand experience that there is
> such a thing as Hell, and it is called Optional Parens.

Optional parens definitely do not help with generic code - quite the
opposite. In generic code, it needs to be clear whether a symbol is supposed
to represent a field or a function. If it's a field, you call it without
parens. If it's a function, it has to be called with parens if it's supposed
to be possible to have the symbol emulate a function rather than be a
function (e.g. be a delegate).

We mostly get away with optional parens on function calls in generic code,
because it's pretty rare that we write code that's expecting a function and
is given a delegate, except in the cases (like predicates) where we clearly
expect any kind of callable, and we have to use template wrappers (e.g.
std.functional.binary) in those cases in order to make them all act the same
and not care about what exactly we're getting.

For symbols that are supposed to act like fields, they can't be called with
parens in generic code, or they won't work generically, and unlike with
symbols that are supposed to act like functions, it's _very_ common to get a
mix of variables and functions for the same symbol across different types.
So, generic code that uses parens on what is supposed to be a field will
work with a function but fail miserably if the type it's given implemented
that symbol as a variable. And that's common enough that generic code needs
to get it right, whereas it can mostly get away with it with symbols that
represent functions simply due to the fact that they're pretty much always
implemented as functions.

I don't think that there's any question that generic code would be better
off if we didn't have optional parens and if functions which used the
property syntax weren't allowed to be called with parens. And D programs
typically have a lot of generic code.

The problem is that when folks are writing code that uses generic functions
(rather than necessarily being inside of generic functions), they like to
leave off the parens and think that it's ugly to be required to have them.
So, we don't have full property enforcement and will never get it. But that
same laxity inside of generic code easily leads to compilation failures when
properties are used simply because a function will work with parens (be it
an @property function or not) whereas variables won't.

Hands down, I think that we'd be better off with strict property enhancement
due to all of the generic code that we deal with, but that water is long
since under the brigde.

Instead, we're forever going to be forced to be even more thorough with unit
testing in order to make sure that templated functions don't use parens on
symbols that are supposed to be properties/fields and to make sure that it
does use parens on something that is supposed to be a function. Since, any
time we don't do that, we risk making mistakes and writing generic code that
doesn't work with all of the types that it's supposed to work with.

The only question at this point is whether we can at least get partial
property enforcement out of @property and reduce the number of bugs in
generic code or whether @property is pretty much just going to be tossed
out.

- Jonathan M Davis