Denis Koroskin <2korden@gmail.com> wrote:
> On Mon, 08 Sep 2008 11:11:30 +0400, Sergey Gromov <snake.scaly@gmail.com> wrote:
> 
> > Manfred_Nowak <svv1999@hotmail.com> wrote:
> >> Sergey Gromov wrote:
> >>
> >> > you essentially define (semantically)
> >> >
> >> >      class char[] {
> >> >           bool equals(char[] b) {...}
> >> >      }
> >>
> >> But then one semantically inherets that class---and therefore should be able to override/overload the inhereted methods, but you deny this. Why?
> >
> > You cannot derive from an array.  When you define
> >
> >     class A {
> >         bool equals(Object o) {...}
> >     }
> >
> > you define a method, A.equals(), which cannot be called for an object of
> > char[] class.
> >
> > Of course not everything is that nice. Consider
> >
> >     bool equals(char[] a, char[] b) {...}
> >     class A {
> >         bool equals(char[] a, char[] b) {...}
> >         bool foo() {
> >             char[] x, y;
> >             bool r1 = equals(x, y);  // I expect A.equals() to be called
> >             bool r2 = x.equals(y);   // I expect .equals() to be called
> >         }
> >     }
> >
> > Here syntax dictates different expectations for something which semantically must be the same.  So I personally put this 'unified function call' feature in the same basket with property call syntax: a 'sugar' which brings more ambiguity to the language than it actually helps rapid development.
> 
> There is not that much of an ambiguity. First of all, member functions can not be used as Unified Function Call, only free ones. That's why your example is perfectly valid, I think that everyone expect the same behaviour. It's just a compiler who is doing things wrong (and bugs are already reported).

What is a 'free' function?  How do you define a search rule?  Consider:

    bool equals(char[] a, char[] b) {...}
    class A {
        bool equals(char[] a, char[] b) {...}
        bool foo() {
            bool equals(char[] a, char[] b) {...}
            char[] x, y;
            bool r1 = equals(x, y);  // calls local equals()
            bool r2 = x.equals(y);   // should call local equals(), too
        }
    }

Here x.equals(y) cannot be rewritten as .equals(x, y) because it will call global equals() instead of the local one.  This means that for x.equals(y) only local and global functions must be considered but any methods should be ignored, despite the fact that they are perfectly accessible from the call scope.  This requires inventing new scoping rules => not quite a 'syntax sugar' anymore.

Frank Benoit schrieb:
> This feature is planned for D2 and is currently available for array types.
> 
> If a global function exists like this:
> 
> bool equals(char[] a, char[] b){
>   return a == b;
> }
> 
> It is possible to use it like this:
> char[] str1 = ...;
> char[] str2 = ...;
> 
> str1.equals( str2 ); // compiles OK
> 
> But if this is used from within a class that also has a method with the
> name "equals" the syntax above does not work any more:
> 
> class A {
>   bool equals( Object o ){ ... }
>   void foo (){
>     bool res = str1.equals(str2); // compile error
>       // equals(Object) does not
>       // match parameter types (char[],char[])
> 
>     bool res2 = .equals(str1,str2); // compile OK
>   }
> }
> 
> Is this a bug or feature?
> 
> Will that syntax work with the planned unified function call syntax in D2?
> 
> 

bool res = str1.equals(str2); // compile error

should become consequently
str1..equals(str2);

seams to be reasonable, bjoern