Overloading property vs. non-property

[Robert Jacques]

On Sat, 17 Jul 2010 10:34:28 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> 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

Thank you for that excellence explanation/clarification.

I'm also hopeful for Functions-as-methods, although you may be borrowing  
trouble with your example. It appears that templates are not included in  
T.init's scope as the following compiles:

struct Bar {
     void foo(T)() if (!is(bar.foo!int)) { writeln("recursive"); }
}

void foo( T)(T x) if (!is(T.init.foo())) { writeln("recursive"); }
void foo2(T)(T x) if (!is(T.init.foo())) { writeln("recursive"); }

void main(string[] args) {
     Bar b;
     b.foo!int;

     int[] bar;
     bar.foo;
     bar.foo2;

     return;
}

As for @properties and Methods-as-properties, I know I dropped out of the  
properties debate when the removal of Methods-as-properties was taken out  
of the proposal. The more I use @property and see it used, the more I feel  
that it's solving its motivating problems by exclusion: i.e. it's fixing a  
problematic corner case by virally applying itself to everything else. So  
perhaps like throw and nothrow, noproperty would be a superior alternative  
to property. But in either case, no/property is a preemptive /  
retrospective patch to the problem of opCall hijacking. And although I  
appreciate the value of having the tools to fix an opCall hijack once  
detected, I'd much rather have a generic solution that detects them at  
compile-time.