"Barry Pederson" <barryp@yahoo.com> wrote in message news:3CA35185.1070805@yahoo.com...
> If I understand correctly, you mean the compiler would treat all these the
> same way:
>    if (b[] == a)
>    if (b[] == a[])
>    if (b[] == a[0..a.length])

Yes.

> So I'm still scratching my head over this, and curious as to why it's a problem.  Not so much to press the point of advocating that particular syntax, but mainly because it's kind if enlightening to be observing the beginning of a new language and pick up little tidbits here and there from Walter as to why things are or aren't workable for a compiler.

The problem is how do you say you want to compare the contents of the array instead of the reference to the array?

"Rchard Krehbiel" <krehbiel3@comcast.net> wrote in message news:a802rh$13io$1@digitaldaemon.com...
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a7tdul$2oan$1@digitaldaemon.com...
> > Comparing references is, in fact, more frequent than comparing values, for objects.
> I don't think this is correct.
> The only time I can imagine caring if Object a refers to the same thing as
> Object b is when I'm writing the "element delete" function for a
> singly-linked list. And with with decent collection class libraries, I
> shouldn't be needing to do that.

I use it often when, for example, doing a reverse lookup on an array. I use it in the thread package to determine if the 'this' refers to the currently executing thread or not.

"Walter" <walter@digitalmars.com> wrote in message news:a9hp9p$12cf$1@digitaldaemon.com...
>
> "Rchard Krehbiel" <krehbiel3@comcast.net> wrote in message news:a802rh$13io$1@digitaldaemon.com...
> > "Pavel Minayev" <evilone@omen.ru> wrote in message news:a7tdul$2oan$1@digitaldaemon.com...
> > > Comparing references is, in fact, more frequent than comparing values, for objects.
> > I don't think this is correct.
> > The only time I can imagine caring if Object a refers to the same thing
as
> > Object b is when I'm writing the "element delete" function for a singly-linked list. And with with decent collection class libraries, I shouldn't be needing to do that.
>
> I use it often when, for example, doing a reverse lookup on an array. I
use
> it in the thread package to determine if the 'this' refers to the
currently
> executing thread or not.

But, do you compare references *more* *often* than you compare content?  How often would a reference comparison be a mistake rather than the intent?

I think content comparison is much more likely to be a programmer's intent, so when he codes "if(objA == objB)", do a content comparison.  When he intends reference comparison, he can code "if(&objA == &objB)".

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@comcast.net  (personal)

"Richard Krehbiel" <rich@kastle.com> wrote in message news:a9hq7r$1385$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message
> But, do you compare references *more* *often* than you compare content?
How
> often would a reference comparison be a mistake rather than the intent?

Hard to say. With string arrays, I compare content. With objects, I compare references.

> I think content comparison is much more likely to be a programmer's
intent,
> so when he codes "if(objA == objB)", do a content comparison.  When he
> intends reference comparison, he can code "if(&objA == &objB)".

&x means the address of the reference. I don't think that will semantically work.

Hmm, maybe "if (a [==] b)" ?? I have to think about this some more.

Walter wrote:

> 
>>so when he codes "if(objA == objB)", do a content comparison.  When he
>>intends reference comparison, he can code "if(&objA == &objB)".
> 
> 
> &x means the address of the reference. I don't think that will semantically
> work.
> 
> Hmm, maybe "if (a [==] b)" ?? I have to think about this some more.

Ewwwww.

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CBCCA22.9030407@estarcion.com...
> Walter wrote:
> > Hmm, maybe "if (a [==] b)" ?? I have to think about this some more.
> Ewwwww.

<cough cough> I guess that settles it <g>

Walter wrote:

> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CBCCA22.9030407@estarcion.com...
> > Walter wrote:
> > > Hmm, maybe "if (a [==] b)" ?? I have to think about this some more.
> > Ewwwww.
>
> <cough cough> I guess that settles it <g>

Well, how about:  "if (a is b)"?

Yes, YAKW (Yet Another KeyWord).  But it does flow, doesn't it?

We could always FORTRAN-ize it:  "if (a .IS. b)"

How about a trigraph?


-BobC

On Tue, 16 Apr 2002 12:21:21 -0700, "Walter" <walter@digitalmars.com> wrote:
> 
> &x means the address of the reference. I don't think that will semantically work.
> 
> Hmm, maybe "if (a [==] b)" ?? I have to think about this some more.
> 
if ( a := b )
if ( a === b )    // my favorite -- they are really, really  the same
if ( a <eq> b )
if ( identical ( a, b ) )

Karl Bochert

"Walter" <walter@digitalmars.com> wrote in message news:a9i80p$1v5a$1@digitaldaemon.com...

> &x means the address of the reference. I don't think that will
semantically
> work.

Yep, right.

> Hmm, maybe "if (a [==] b)" ?? I have to think about this some more.

I remember you proposed === for arrays, maybe the same for objects?

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a7tk0m$2rgu$1@digitaldaemon.com...
> Sorry for grabbing the hand as soon as you give me a
> finger, but I love the concept of operator overloading,
> and this would make it fairly transparent to implement.
> Also, operator overloading haters could always directly
> call the normal functions.

It does seem like I've fallen backwards into supporting operator overloading <g>.