Hi,

   Shouldn't the precedence of the new operator be greater than the .
operator? Look the following piece of code:

class A {
   this() {
   }
   public int eq(Object obj) {
      return true;
   }
}
unittest {
   assert(new A() == new A());
   assert(new A().eq(new A()));   // compiler error
   assert((new A()).eq(new A())); // ok but clumsy
}

   I think this usage is unambiguous, so it shouldn't require a pair of
parenthesis.

    Best regards,
    Daniel Yokomiso.

This might be a counterexample:

class B
{
    alias int mytype;
}
unittest
{
   assert(new B.mytype() == new int());
}

I suppose the placement of the ctor call parens is important.  So operator new should bind all of the specified type up until the first open parenthesis?  This looks subtle to me;  it also seems important to get it right.  I'd agree that your "broken" example should in fact be made to work. That's what most people would expect.

One big clue here is that expressions cannot produce types (or can they? You certainly can't have a function return a type), but scope resolution can.  D uses the dot operator for both.  (in an expression, dot boils down to pointer dereferencing.)

Sean

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:aqej08$271i$1@digitaldaemon.com...
> Hi,
>
>    Shouldn't the precedence of the new operator be greater than the .
> operator? Look the following piece of code:
>
> class A {
>    this() {
>    }
>    public int eq(Object obj) {
>       return true;
>    }
> }
> unittest {
>    assert(new A() == new A());
>    assert(new A().eq(new A()));   // compiler error
>    assert((new A()).eq(new A())); // ok but clumsy
> }
>
>    I think this usage is unambiguous, so it shouldn't require a pair of
> parenthesis.
>
>     Best regards,
>     Daniel Yokomiso.
>
>

In article <aqfs4s$fht$1@digitaldaemon.com>, Sean L. Palmer says...
>
>This might be a counterexample:
>
>class B
>{
>    alias int mytype;
>}
>unittest
>{
>   assert(new B.mytype() == new int());
>}
>
>I suppose the placement of the ctor call parens is important.  So operator new should bind all of the specified type up until the first open parenthesis?  This looks subtle to me;  it also seems important to get it right.  I'd agree that your "broken" example should in fact be made to work. That's what most people would expect.
>
>One big clue here is that expressions cannot produce types (or can they? You certainly can't have a function return a type), but scope resolution can.  D uses the dot operator for both.  (in an expression, dot boils down to pointer dereferencing.)
>
>Sean
>
>"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:aqej08$271i$1@digitaldaemon.com...
>> Hi,
>>
>>    Shouldn't the precedence of the new operator be greater than the .
>> operator? Look the following piece of code:
>>
>> class A {
>>    this() {
>>    }
>>    public int eq(Object obj) {
>>       return true;
>>    }
>> }
>> unittest {
>>    assert(new A() == new A());
>>    assert(new A().eq(new A()));   // compiler error
>>    assert((new A()).eq(new A())); // ok but clumsy
>> }
>>
>>    I think this usage is unambiguous, so it shouldn't require a pair of
>> parenthesis.
>>
>>     Best regards,
>>     Daniel Yokomiso.
>>
>>
>
>

Hi,

Yes, you are right. There are some other couterexamples, like template class instantiation, you always have something like:

template TA(T) {
class A {
public int eq(Object obj) {
return true;
}
}
}
unittest {
instance TA(int) ta;
assert(new ta.A() == new ta.A());
}

Java has the same problem, they provide inner classes, so the syntax new B.A()
is valid (if A is a static inner class of B). But they allow new
B.A().equals(new B.A()). It's just a nitpick right now, but consistency is good
:-)

Best regards,
Daniel Yokomiso.