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

[Andrei Alexandrescu]

On 1/25/13 12:17 PM, Rob T wrote:
> On Friday, 25 January 2013 at 16:43:45 UTC, Jesse Phillips wrote:
> [...]
>> That said many that want @property, want optional parens to die, as
>> shown by your side comment that follows.
>>
>
> I think that observation pins the whole debate down, and it's an
> incredible amount of debate for something that boils down little more
> than personal taste. We don't even need property-like behavior, it's not
> that important. Meanwhile really serious problems exist that are not
> being attended to.
>
> The concept of a property works perfectly fine without explicit
> @property enforcement (except for perhaps an edge case or two that can
> be corrected). When I started with D, the TDPL told me that I had to put
> @property in, and it was actually a relief to discover that I did not
> have to do that. It's a waste of time, and more than half the time I
> could not decide if I wanted property-like behavior or not, so the lack
> of enforcement was a plus for me.
>
> If the default behavior is optional parens plus no @property
> enforcement, i.e., the current behavior, then for the people who want to
> change the default behavior need to specify @property and we implement
> enforcement for those situations. However, for the remaining functions,
> the property behavior is optional and not enforced, so some means such
> as the @function proposal will be needed to enforce the traditional
> c-like function call syntax.
>
> But is there any real need for the extra complications of implementing
> property and c-style function call enforcement? This is D and there's no
> law that states that D must behave exactly like C.
>
> I think Walters proposal to shoot @property is perfectly sound. Get rid
> of it, fix the edge cases, and move on to solving the problems that
> matter a whole lot more than this one.
>
> If Walter's proposal is not sound, then we need real clear technical
> reasons why enforcement is required, as opposed to arguments that boil
> down to personal tastes.

I agree with all of the above. There has been a fair amount of 
rationalization and appeal to emotion on all sides. It would be great to 
get back to reason and clearly compartmentalize objective arguments (of 
which there have been a few very profound ones) and personal preference.

On the objective side there are a few challenges that have been well 
discussed:

1. Syntactic and semantic implications of properties that return 
callable entities

2. Introspection, how does one distinguish between a genuine field and a 
property when necessary

3. Impact on existing and future code

On the subjective side, Walter's and my opinion and experience have been 
largely aligned. With that in mind but speaking for myself unless 
otherwise noted, here are some bits of my subjective opinion:

1. In C and C++ the syntax "func" or "object.method" does nothing 
interesting or useful. In C, "func" is actually equivalent with "&func". 
In C it's actually worse, "func" yields the type "reference to function" 
which is highly restricted and obeys some rather arcane rules (in 
particular it's implicitly convertible to pointer to function).

C has no methods so the syntax "object.method" does not apply to it. In 
C++, "object.method" is probably the oddest construct in the entire 
language: it returns a type that exists but has no name, is not 
expressible syntactically, is not first class (one can't assign 
"object.method" to a variable), and has only two allowed operations: 
take address or apply the function call operator "()". Various C++ 
implementations have extensions that fix this.

Both Walter and I consider these serious lapses in language design. Two 
of the most accessible elements of syntax do things of considerably low 
interest and use. I hope I now clarified why I have a dim view of 
arguments that - implicitly or explicitly - assume the C or C++ behavior 
in this area is an example to follow on technical grounds. (Clearly, 
familiarity is a much better argument.)

2. I have tried to add @property appropriately in Phobos, in particular 
for ranges:

struct SomeRange {
   @property bool empty();
   @property ref T front();
   void popFront();
}

There's more "@property" to be seen with "save" and "back". Subjectively 
that just didn't work well for me. It adds clutter to an otherwise 
simple and straightforward API, and penalizes usage for benefits that I 
could never reap. I understand how some people are glad to put that in 
everywhere, and find meaning in requiring parens with popFront and 
popBack but not the others. Yet for me it was liberating (see 1 above 
too) I could just write "r.popFront" without the parens and have it do 
its deed. It is the right semantics for a simple syntax.

3. Whatever we do going forward should be _simple_ but not _simplistic_. 
Right now it's easy to forget that we're all close to the subject. We 
have it in working memory (at least it's what I think about all the 
time) and any incremental complexity is an easy cost to absorb 
intellectually.

But when we need to teach this to newcomers or even approach it again 
with a "cold cache", any undue complexity will be jarring.

4. Whether we like it or not, backward compatibility is an issue. The 
parens or no parens aspect upon a function call is too ubiquitous to 
write off as an obscure circumstance. So I don't think the obscurity 
argument applies.

Granted, there are several ways to approach the compatibility issue, all 
with their specific tradeoffs. All I'm saying is that careful 
considerations of compatibility must be integral to whatever we do about 
this.

5. This is a matter in which reasonable people may disagree. For better 
or worse Walter and to a lesser extent myself are in the position to 
decide. We're doing the best to gather, mind, and integrate opinions and 
suggestions but clearly no decision that would please everyone. So 
please bear with us. I understand this may be frustrating but the best 
we all can do is think beyond our own preference and on behalf of the 
larger community.


Thanks,

Andrei