Overloading property vs. non-property

[Andrei Alexandrescu]

Robert Jacques wrote:
> Before reading TDPL I'd had agreed with you 100%. Now, I find that TDPL 
> is either ambiguous or anticipatory in a small number of cases. For 
> example, Functions-as-Methods get more exposure than @property, but no 
> limitations are mentioned nor are there any generalized examples 
> presented. So is the feature limited to arrays (current DMD) or 
> available to all types (Slide-ware from the D conference)? Clear and the 
> removal of delete got a solid paragraph of explanation and rational, but 
> recent discussions have highlighted issues. And while I believe these 
> issues to be solvable, as the devil is always in the details, this might 
> not always be the case where TDPL anticipates DMD. By contrast, 
> @property literally gets 1 line of text, 2 off-hand code uses and 
> Methods-as-Properties is never mentioned. So was Methods-as-Properties 
> not mentioned because it was dropped from the spec or because TDPL is 
> downright laconic with regard to properties in general?

It's quite reasonable to not want to give very much detail about 
features that are not yet fully implemented - that was the only motivation.

What Walter and I had in mind was to remove methods-as-properties in 
favor of @property. He mentioned that that would break quite a bit of 
code in Phobos so it needs to be introduced with care. The current plan 
is to initially enable it as a compiler switch.

Functions-as-methods is, I think, a good feature. I've encountered one 
issue with them: it's difficult to define a function if there's no 
method with the same name. Consider we want to define foo(T) if T does 
not have a method foo():

void foo(T) if (!is(T.init.foo())) { ... }

This works today. However, with the new rule things are dicey. The 
foo(T) free function is introduced before evaluating the constraint. So 
T.init.foo() does find it. What happens currently (if T is an array 
type) is infinite recursion during compilation.

I think the problem is solvable - I just introduced hasMember(T, string) 
  in std.traits that looks up straight in T's symbol table. So the 
rewritten condition would be:

void foo(T) if (!hasMember!(T, "foo") || !is(T.init.foo())) { ... }

Assuming short-circuit evaluation, it all works but it's rather subtle.

Since recently, however, Walter became very adverse to introducing 
breaking changes of any kind. He understandably wants to promote 
stability of the language. The only question is whether stability refers 
to the compiler's status quo or TDPL.

Finally, I should mention that we decided relatively early within the 
book that TDPL won't be a reference manual including every single detail 
of the language; it would have inflated with a lot of boring details. 
Not even K&R is a complete reference to C, even as it was back when the 
book was written.


Andrei