• Daniel Yokomiso (19/19) Nov 07 2002 Hi,
• Sean L. Palmer (21/40) Nov 08 2002 This might be a counterexample:
• Daniel Yokomiso (21/67) Nov 08 2002 Hi,

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

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.

"Sean L. Palmer" <seanpalmer directvinternet.com> writes:

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.

Daniel Yokomiso <Daniel_member pathlink.com> writes:

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.