> > While I'm all in favor of replacing === with 'is', I'm not quite sure how this is going to help your porting problem.  It still seems like you are stuck with a case by case decision of replacing == with 'is'.
>
> Gah! You're right. What a dumbo! <blush>
>
> So it's all so much more hideous than I was thinking.
>
> I'm going to skulk in a corner until I can think of a solution. I may be some time ...
>

If your C/C++ code uses pointers, why don't you use pointers in D? Leave the D stuff to code specifically for D.

After thinking about it and playing with it a little bit I agree === is a disaster waiting to happen.  How about a new equality operator ?  Shall we vote on it ?  Ive set up a poll at : http://groups.yahoo.com/group/DigitalMD/surveys?id=11324569

C
"Charles Sanders" <sanders-consulting@comcast.net> wrote in message
news:bm9tl3$279r$1@digitaldaemon.com...
> > People will rightly say that D has fostered entirely new methods of writing invalid code.
>
> I see what your saying but it seems only a problem when porting code.  I agree that its very easy to overlook, but i dont see how 'is' will solve
it,
> u still have to hunt down all those instances and replace them.
>
> C
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bm9qvj$23dg$1@digitaldaemon.com...
> > No. I'm saying that when porting code, i.e. copying C or C++ code (in)to
> D,
> > the translation of != and == to !== and === can be overlooked, and the compiler does nothing to help. Since porting code will feature large,
this
> > is a certain accident waiting to happen. To be honest, I'm not even sure that I've got every instance covered in the small amount of code I did yesterday. In principle it is impossible to guarantee that these errors
> will
> > not creep into arbitrarily large amounts of ported code, since one
> operator
> > is a lexical subset of the other, and both can be applied to some circumstance.
> >
> > For example (names are chosen for clarity in this case; they're not my naming convention), if I had some C++ code
> >
> > Object *object_ptr
> > if(NULL != object_ptr)
> > {
> >   object_ptr->SomeMethod();
> > }
> >
> > Object &object_ref =
> > if(0 != object_ref) /* Assuming Object is comparable with 0 */
> > {
> >   object_ref.SomeMethod();
> > }
> >
> > Now when I'm porting this to D, I do the following:
> >
> > - Replace NULL with null - this is 100% correctness-assured, since NULL
is
> > not recognised in D
> > - Change all the pointers to D references - this is 100%
> correctnes-assured,
> > since D does not support ->, so we can replace all of those with ., and
> > handle the syntax errors
> > - Change all the C++ references to D references - I've not thought out
> this
> > completely, but I believe it's 100% correctness assured since D doesn't
> > allows the C++ reference declaration notation
> > - Try and change some of the != or == to !== and ===. I need to remember
> to
> > change the first one, and not the second one. In the two cases above, if
I
> > make no change to these operators the compiler is happy. However, the
> first
> > conditional now has a runtime error waiting to kill the process. This
may
> > come out in testing, or it may not. Proving that we've got it correct is theoretically impossible (a la Turing Halting problem), so here comes
> la-la
> > land. People will rightly say that D has fostered entirely new methods
of
> > writing invalid code.
> >
> > (The example may not be the best, as I'm not sure that D objects can be overloadedly comparable with integral values, but I think you get the
> idea.)
> >
> > Is this clear? If it's not, I'll try again, because this is so important
> we
> > need to get a quorum of worried folks to badger Walter into changing it. Otherwise, D-knockers have got a big gun to shoot it with.
> >
> >
> > "Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bm9nsa$1vcu$1@digitaldaemon.com...
> > > Im not sure what you mean actually, your saying that when wrapping the
C
> > > code in extern () blocks that the pointer comparison has to be
manually
> > > changed to === and !== , and that this causes a bunch of errors ?
> > Admitedly
> > > I havent done any real porting so I dont have much of an argument
other
> > than
> > > i think its 'purtier' than "is" ( although I am working with Y. Tomino
> to
> > > get win32.lib easy to use, requiring alot of .def files and exports to
> get
> > > it to work.  Right now the only way I can see to do it is for each
.dll
> ,
> > > write a corresponding .def file that maps all the functions to ther
> > > _XXX@(num) counterparts.  Is this really the only way ? This will take
> > > forever ... )
> > >
> > > Also congrats on the new column :D.
> > >
> > > C
> > >
> > >
> > > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bm9mub$1u0b$1@digitaldaemon.com...
> > > >
> > > > "Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bm9hl9$1n09$1@digitaldaemon.com...
> > > > > I know im going againts popular opinion here but i like the === .
I
> > > would
> > > > > prefer if == and != could do the same thing, but if not I would
much
> > > > rather
> > > > > have an operator than 'is [of]'.  The operator helps maintain a
> level
> > of
> > > > > continuity.
> > > >
> > > > That's nice to know, ;), but you've not addressed my porting issue.
Do
> > you
> > > > think it's wrong, or that I've overstated the case, or you're not interested?
> > > >
> > > >
> > > > > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bm7c3d$1pqi$1@digitaldaemon.com...
> > > > > > Porting code from C/C++ is a minefield. Comparing pointers
> requires
> > > > > > translating ==/!= to ===/!==, whereas doing it for other types
> > > requires
> > > > > > ==/!= be preserved. The compiler does *nothing* to help, since
> it's
> > > > quite
> > > > > > happy with the syntax if you forget/omit the extra "=" - it all
> > still
> > > > > > compiles. Who knows when these erroneous constructs will bite at
> > > > runtime?
> > > > > > The first time it's run? After 1,000,000 executions? It's the
> Turing
> > > > > Halting
> > > > > > problem, and its' NP.
> > > > > >
> > > > > > Please, please, please, please, please can we get rid of === and
> > !==,
> > > > and
> > > > > > replace them with something that will not (or at least, less
> easily)
> > > > > > facilitate undetectable errors entering code? My suggestion is
> "is"
> > > and
> > > > > "is
> > > > > > not", but I'm not particularly stuck on that. Anything that will
> > avoid
> > > > > these
> > > > > > errors.
> > > > > >
> > > > > > The only alternative that will save us from unknown numbers of
> > errors
> > > is
> > > > > to
> > > > > > proscribe all porting and require everything to be written anew.
> > > (Sounds
> > > > > of
> > > > > > myriad potential doors slamming ...)
> > > > > >
> > > > > > Yours portentously
> > > > > >
> > > > > > Freddie
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Yes, as I said in another post, I've over-simplified the solution to this very nasty problem.

The port-savvy approach would be for D to not use == and != (forget === and !== for the moment), which clearly isn't a solution.

This is the stuff I really hate with languages that fake references from real pointers.

I guess the solution is to create a C++ => D pre-porter, which finds all == and != and simply replaces them with some invalid character sequence. This would then force the porter to examine each and every case. (Maybe I'll write one to do it for a whole directory structure, using recls of course. :) )

This really chews. Imagine all the bugs that are going to come in as a result of this. :(


"Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bm9tl3$279r$1@digitaldaemon.com...
> > People will rightly say that D has fostered entirely new methods of writing invalid code.
>
> I see what your saying but it seems only a problem when porting code.  I agree that its very easy to overlook, but i dont see how 'is' will solve
it,
> u still have to hunt down all those instances and replace them.
>
> C
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bm9qvj$23dg$1@digitaldaemon.com...
> > No. I'm saying that when porting code, i.e. copying C or C++ code (in)to
> D,
> > the translation of != and == to !== and === can be overlooked, and the compiler does nothing to help. Since porting code will feature large,
this
> > is a certain accident waiting to happen. To be honest, I'm not even sure that I've got every instance covered in the small amount of code I did yesterday. In principle it is impossible to guarantee that these errors
> will
> > not creep into arbitrarily large amounts of ported code, since one
> operator
> > is a lexical subset of the other, and both can be applied to some circumstance.
> >
> > For example (names are chosen for clarity in this case; they're not my naming convention), if I had some C++ code
> >
> > Object *object_ptr
> > if(NULL != object_ptr)
> > {
> >   object_ptr->SomeMethod();
> > }
> >
> > Object &object_ref =
> > if(0 != object_ref) /* Assuming Object is comparable with 0 */
> > {
> >   object_ref.SomeMethod();
> > }
> >
> > Now when I'm porting this to D, I do the following:
> >
> > - Replace NULL with null - this is 100% correctness-assured, since NULL
is
> > not recognised in D
> > - Change all the pointers to D references - this is 100%
> correctnes-assured,
> > since D does not support ->, so we can replace all of those with ., and
> > handle the syntax errors
> > - Change all the C++ references to D references - I've not thought out
> this
> > completely, but I believe it's 100% correctness assured since D doesn't
> > allows the C++ reference declaration notation
> > - Try and change some of the != or == to !== and ===. I need to remember
> to
> > change the first one, and not the second one. In the two cases above, if
I
> > make no change to these operators the compiler is happy. However, the
> first
> > conditional now has a runtime error waiting to kill the process. This
may
> > come out in testing, or it may not. Proving that we've got it correct is theoretically impossible (a la Turing Halting problem), so here comes
> la-la
> > land. People will rightly say that D has fostered entirely new methods
of
> > writing invalid code.
> >
> > (The example may not be the best, as I'm not sure that D objects can be overloadedly comparable with integral values, but I think you get the
> idea.)
> >
> > Is this clear? If it's not, I'll try again, because this is so important
> we
> > need to get a quorum of worried folks to badger Walter into changing it. Otherwise, D-knockers have got a big gun to shoot it with.
> >
> >
> > "Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bm9nsa$1vcu$1@digitaldaemon.com...
> > > Im not sure what you mean actually, your saying that when wrapping the
C
> > > code in extern () blocks that the pointer comparison has to be
manually
> > > changed to === and !== , and that this causes a bunch of errors ?
> > Admitedly
> > > I havent done any real porting so I dont have much of an argument
other
> > than
> > > i think its 'purtier' than "is" ( although I am working with Y. Tomino
> to
> > > get win32.lib easy to use, requiring alot of .def files and exports to
> get
> > > it to work.  Right now the only way I can see to do it is for each
.dll
> ,
> > > write a corresponding .def file that maps all the functions to ther
> > > _XXX@(num) counterparts.  Is this really the only way ? This will take
> > > forever ... )
> > >
> > > Also congrats on the new column :D.
> > >
> > > C
> > >
> > >
> > > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bm9mub$1u0b$1@digitaldaemon.com...
> > > >
> > > > "Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bm9hl9$1n09$1@digitaldaemon.com...
> > > > > I know im going againts popular opinion here but i like the === .
I
> > > would
> > > > > prefer if == and != could do the same thing, but if not I would
much
> > > > rather
> > > > > have an operator than 'is [of]'.  The operator helps maintain a
> level
> > of
> > > > > continuity.
> > > >
> > > > That's nice to know, ;), but you've not addressed my porting issue.
Do
> > you
> > > > think it's wrong, or that I've overstated the case, or you're not interested?
> > > >
> > > >
> > > > > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bm7c3d$1pqi$1@digitaldaemon.com...
> > > > > > Porting code from C/C++ is a minefield. Comparing pointers
> requires
> > > > > > translating ==/!= to ===/!==, whereas doing it for other types
> > > requires
> > > > > > ==/!= be preserved. The compiler does *nothing* to help, since
> it's
> > > > quite
> > > > > > happy with the syntax if you forget/omit the extra "=" - it all
> > still
> > > > > > compiles. Who knows when these erroneous constructs will bite at
> > > > runtime?
> > > > > > The first time it's run? After 1,000,000 executions? It's the
> Turing
> > > > > Halting
> > > > > > problem, and its' NP.
> > > > > >
> > > > > > Please, please, please, please, please can we get rid of === and
> > !==,
> > > > and
> > > > > > replace them with something that will not (or at least, less
> easily)
> > > > > > facilitate undetectable errors entering code? My suggestion is
> "is"
> > > and
> > > > > "is
> > > > > > not", but I'm not particularly stuck on that. Anything that will
> > avoid
> > > > > these
> > > > > > errors.
> > > > > >
> > > > > > The only alternative that will save us from unknown numbers of
> > errors
> > > is
> > > > > to
> > > > > > proscribe all porting and require everything to be written anew.
> > > (Sounds
> > > > > of
> > > > > > myriad potential doors slamming ...)
> > > > > >
> > > > > > Yours portentously
> > > > > >
> > > > > > Freddie
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Wow. I didn't realize != didn't accept nulls. I'm so used to writing "!=
null" from C and Java (and C#) that I can see converting to "!== null" would
be error prone and annoying. Why not keep C's defn of == and != and instead
do what Java did and make another "deep equals" operator or function?
I can see how in principle D's current definition of == and === make sense
and are nice, but the reality is that many many people will be switching
back and forth between C (and the other C-like languages) and D and this
will be a nasty "gochta".

In terms of worrying about == for "Object *obj" vs "Object &obj"... that doens't bother me as much since porting "Object &obj" to D requires special attention anyway.

-Ben

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bm9qvj$23dg$1@digitaldaemon.com...
> No. I'm saying that when porting code, i.e. copying C or C++ code (in)to
D,
> the translation of != and == to !== and === can be overlooked, and the compiler does nothing to help. Since porting code will feature large, this is a certain accident waiting to happen. To be honest, I'm not even sure that I've got every instance covered in the small amount of code I did yesterday. In principle it is impossible to guarantee that these errors
will
> not creep into arbitrarily large amounts of ported code, since one
operator
> is a lexical subset of the other, and both can be applied to some circumstance.
>
> For example (names are chosen for clarity in this case; they're not my naming convention), if I had some C++ code
>
> Object *object_ptr
> if(NULL != object_ptr)
> {
>   object_ptr->SomeMethod();
> }
>
> Object &object_ref =
> if(0 != object_ref) /* Assuming Object is comparable with 0 */
> {
>   object_ref.SomeMethod();
> }
>
> Now when I'm porting this to D, I do the following:
>
> - Replace NULL with null - this is 100% correctness-assured, since NULL is
> not recognised in D
> - Change all the pointers to D references - this is 100%
correctnes-assured,
> since D does not support ->, so we can replace all of those with ., and
> handle the syntax errors
> - Change all the C++ references to D references - I've not thought out
this
> completely, but I believe it's 100% correctness assured since D doesn't
> allows the C++ reference declaration notation
> - Try and change some of the != or == to !== and ===. I need to remember
to
> change the first one, and not the second one. In the two cases above, if I make no change to these operators the compiler is happy. However, the
first
> conditional now has a runtime error waiting to kill the process. This may come out in testing, or it may not. Proving that we've got it correct is theoretically impossible (a la Turing Halting problem), so here comes
la-la
> land. People will rightly say that D has fostered entirely new methods of writing invalid code.
>
> (The example may not be the best, as I'm not sure that D objects can be overloadedly comparable with integral values, but I think you get the
idea.)
>
> Is this clear? If it's not, I'll try again, because this is so important
we
> need to get a quorum of worried folks to badger Walter into changing it. Otherwise, D-knockers have got a big gun to shoot it with.
>
>
> "Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bm9nsa$1vcu$1@digitaldaemon.com...
> > Im not sure what you mean actually, your saying that when wrapping the C code in extern () blocks that the pointer comparison has to be manually changed to === and !== , and that this causes a bunch of errors ?
> Admitedly
> > I havent done any real porting so I dont have much of an argument other
> than
> > i think its 'purtier' than "is" ( although I am working with Y. Tomino
to
> > get win32.lib easy to use, requiring alot of .def files and exports to
get
> > it to work.  Right now the only way I can see to do it is for each .dll
,
> > write a corresponding .def file that maps all the functions to ther
> > _XXX@(num) counterparts.  Is this really the only way ? This will take
> > forever ... )
> >
> > Also congrats on the new column :D.
> >
> > C
> >
> >
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bm9mub$1u0b$1@digitaldaemon.com...
> > >
> > > "Charles Sanders" <sanders-consulting@comcast.net> wrote in message news:bm9hl9$1n09$1@digitaldaemon.com...
> > > > I know im going againts popular opinion here but i like the === .  I
> > would
> > > > prefer if == and != could do the same thing, but if not I would much
> > > rather
> > > > have an operator than 'is [of]'.  The operator helps maintain a
level
> of
> > > > continuity.
> > >
> > > That's nice to know, ;), but you've not addressed my porting issue. Do
> you
> > > think it's wrong, or that I've overstated the case, or you're not interested?
> > >
> > >
> > > > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bm7c3d$1pqi$1@digitaldaemon.com...
> > > > > Porting code from C/C++ is a minefield. Comparing pointers
requires
> > > > > translating ==/!= to ===/!==, whereas doing it for other types
> > requires
> > > > > ==/!= be preserved. The compiler does *nothing* to help, since
it's
> > > quite
> > > > > happy with the syntax if you forget/omit the extra "=" - it all
> still
> > > > > compiles. Who knows when these erroneous constructs will bite at
> > > runtime?
> > > > > The first time it's run? After 1,000,000 executions? It's the
Turing
> > > > Halting
> > > > > problem, and its' NP.
> > > > >
> > > > > Please, please, please, please, please can we get rid of === and
> !==,
> > > and
> > > > > replace them with something that will not (or at least, less
easily)
> > > > > facilitate undetectable errors entering code? My suggestion is
"is"
> > and
> > > > "is
> > > > > not", but I'm not particularly stuck on that. Anything that will
> avoid
> > > > these
> > > > > errors.
> > > > >
> > > > > The only alternative that will save us from unknown numbers of
> errors
> > is
> > > > to
> > > > > proscribe all porting and require everything to be written anew.
> > (Sounds
> > > > of
> > > > > myriad potential doors slamming ...)
> > > > >
> > > > > Yours portentously
> > > > >
> > > > > Freddie
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

"Matthew Wilson" <matthew@stlsoft.org> wrote in news:bm9r94$23qu$1@digitaldaemon.com:

> 
> "Patrick Down" <pat@codemoon.com> wrote in message news:Xns94119FB75D346patcodemooncom@63.105.9.61...
> 
> Gah! You're right. What a dumbo! <blush>
> 
> So it's all so much more hideous than I was thinking.
> 
> I'm going to skulk in a corner until I can think of a solution. I may be some time ...

I think it is wrong to burden the language
with a lot of features that make easier to
port to it or connect it to C libraries.  I
really think that tools should be created
to help with these types of problems.

A header file translator could create wrapper
functions that deal with string issues.

A D lint like program could look for problem
areas in C to D ports.

"Ben Hinkle" <bhinkle4@juno.com> wrote in message news:bmblju$1fss$1@digitaldaemon.com...
> Wow. I didn't realize != didn't accept nulls. I'm so used to writing "!= null" from C and Java (and C#) that I can see converting to "!== null"
would
> be error prone and annoying.

Hmmm. If this only applies to comparisons with null, then there would be a simple solution. Since "== null" will always cause a crash if the == operator is implemented according to spec, the compiler could make this statement illegal and produce a compiler error. So this particular issue could be circumvented.

This won't solve the problem of comparison with a non-constant object reference that has a null value, but I think such cases are less critical.

If "== null" were invalid and the === operator would be renamed to "is", then I think the readability and error safety would be improved a lot.

Btw: has Walter ever commented on renaming the === operator? This issue keeps coming up and I don't remember him ever stating his opinion on this matter.

Hauke