@property - take it behind the woodshed and shoot it?

[Nick Sabalausky]

On Thu, 24 Jan 2013 12:51:32 -0500
Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:

> On 1/24/13 7:13 AM, Bernard Helyer wrote:
> > On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
> >> This has turned into a monster. We've taken 2 or 3 wrong turns
> >> somewhere.
> >>
> >> Perhaps we should revert to a simple set of rules.
> >>
> >> 1. Empty parens are optional. If there is an ambiguity with the
> >> return value taking (), the () go on the return value.
> >>
> >> 2. the:
> >> f = g
> >> rewrite to:
> >> f(g)
> >> only happens if f is a function that only has overloads for () and
> >> (one argument). No variadics.
> >>
> >> 3. Parens are required for calling delegates or function pointers.
> >>
> >> 4. No more @property.
> >
> > This is lazy design, plain and simple. You say it's turned into
> > a monster, but @property, at its core, is simpler than the
> > heuristics you've demonstrated here. To my mind, @property,
> > properly implemented is simple:
> >
> > @property functions may be called with no parens or with assignment
> > as the singular argument. Non @property functions may not.
> >
> > There. No complications. The only complications come from D's
> > history. And then you want to turn it back? This seems a terrible
> > idea -- the deed is done, pull the trigger. Make @property
> > mandatory for property functions.
> 
> No. The complications come from the fact that (a) nobody could agree 
> what should be a @property and what shouldn't;

No, you merely came up with *some* specific cherry-picked examples that
sparked *some* debate (with most of the disagreing coming from
you).

Stop mischaracterizing what really happened:

It's well known that you never liked or fully understood the idea of
properties in the first place, even by your own admission. So you made a
post some number of months back attempting to drum up dissent for
properties by stirring up the notion, which just about only you
believed, that the choice between property and function is inherently
unclear.

So to "prove" this you cherry-picked some grey area cases (gee,
occasional grey judgement calls when mapping ideas into code,
yea, there's something that doesn't happen without @property). You
succeeded ONLY in proving that there exist *some* cases which may be
grey-area judgement calls (again, big surprise, occasional grey-area
judgement calls when writing code). But then you - and ONLY you - took
this proof that "*some* cases exist" and declared "Look, look, everyone!
I proved that *nobody* can agree on property vs function *in general*!
QED!"

And you continue declaring that non-sequitur to this day.

> (b) @property adds
> noise for everybody for the sake of a corner case (functions
> returning delegates);

The only reason functions returning delegates have *ever* been an
any issue at all is *purely* because of the insistence on
optional parens on arbitrary function calls.


> (c) the @property discipline failed to align
> itself in any way with better code quality.
> 

Ok, now *that* argument is just pure unadulterated bullshit. In
languages like C# that have *real* and *completed* property support,
yes, the general consensus IS that they DO definitely help. Please take
your blinders off, and you'll see that.

But then there's D, which adds a half-baked and
incompletely-implemented "properties" - and did so *reluctantly* I
should add. Leaves it in that broken state untouched for a year or two.
And now here you are effectively saying "This
half-designed/half-implemented feature is causing dissent and not
helping people, therefore the problem must be the whole idea of
properties and couldn't possibly be due to our broken version of
them" (for the record - I *do* find D's current properties helpful,
just not as helpful as they would be if they weren't broken).