www.digitalmars.com         C & C++   DMDScript  

D - === / == / !== / != - a recipe for disaster!

reply "Matthew Wilson" <matthew stlsoft.org> writes:
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
Oct 10 2003
next sibling parent reply "Hauke Duden" <H.NS.Duden gmx.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bm7c3d$1pqi$1 digitaldaemon.com...
 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?

\vote yes !!!!! "is" is so much more readable than ===. Anecdotal evidence: I have noted a tendency in myself that when I'm reading code and I see !== I intuitively think that it is the negative form of ==, not ===. I don't want to delve into a psychological analysis of why that is the case here, but I do think too many = signs are just too confusing. I always have to consciously think about what is meant by such an expression. Hauke
Oct 10 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
I agree with that argument in general, even though I've managed to grok the
differences reasonably well over the course of my D experience. That's not
to say that I don't occasionally make the mistake, but it's not often.
However, even for those (few, probably) who are 100% confident and competent
with writing the operators themselves, when porting code there is
*absolutely no way* that anyone is going to achieve the same level of
success. I know this because I'm doing it right now, and the significance of
this issue is only just dawning on me. Where previously I had disliked the
operators for the reasons you have described (which, IMO, are sufficient to
require them to change in an ideal world), I now *know* that they are a
clear and present danger to code correctness.

Sorry to sound so alarmist, but as soon as large (the project I'm converting
now I would call small, as it's less than 3000 LOCs) projects are ported,
the evangelists of all D's competitor languages will have some powerful
evidence to back their current misgivings and prejudices.




"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bm7cvn$1qq5$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bm7c3d$1pqi$1 digitaldaemon.com...
 Please, please, please, please, please can we get rid of === and !==,


 replace them with something that will not (or at least, less easily)
 facilitate undetectable errors entering code?

\vote yes !!!!! "is" is so much more readable than ===. Anecdotal evidence: I have noted a tendency in myself that when I'm reading code and I see !== I intuitively think that it is the negative form of ==, not ===. I don't want to delve into a psychological analysis of why that is the case here, but I do think too many = signs are just too confusing. I always have to consciously

 about what is meant by such an expression.

 Hauke

Oct 10 2003
prev sibling next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
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.

C


"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

 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

 not", but I'm not particularly stuck on that. Anything that will avoid

 errors.

 The only alternative that will save us from unknown numbers of errors is

 proscribe all porting and require everything to be written anew. (Sounds

 myriad potential doors slamming ...)

 Yours portentously

 Freddie

Oct 11 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"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

 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


 happy with the syntax if you forget/omit the extra "=" - it all still
 compiles. Who knows when these erroneous constructs will bite at


 The first time it's run? After 1,000,000 executions? It's the Turing

 problem, and its' NP.

 Please, please, please, please, please can we get rid of === and !==,


 replace them with something that will not (or at least, less easily)
 facilitate undetectable errors entering code? My suggestion is "is" and

 not", but I'm not particularly stuck on that. Anything that will avoid

 errors.

 The only alternative that will save us from unknown numbers of errors is

 proscribe all porting and require everything to be written anew. (Sounds

 myriad potential doors slamming ...)

 Yours portentously

 Freddie


Oct 11 2003
parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
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


 prefer if == and != could do the same thing, but if not I would much

 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



 ==/!= be preserved. The compiler does *nothing* to help, since it's


 happy with the syntax if you forget/omit the extra "=" - it all still
 compiles. Who knows when these erroneous constructs will bite at


 The first time it's run? After 1,000,000 executions? It's the Turing

 problem, and its' NP.

 Please, please, please, please, please can we get rid of === and !==,


 replace them with something that will not (or at least, less easily)
 facilitate undetectable errors entering code? My suggestion is "is"



 "is
 not", but I'm not particularly stuck on that. Anything that will avoid

 errors.

 The only alternative that will save us from unknown numbers of errors



 to
 proscribe all porting and require everything to be written anew.



 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie



Oct 11 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
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 ?

 I havent done any real porting so I dont have much of an argument other

 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


 prefer if == and != could do the same thing, but if not I would much

 have an operator than 'is [of]'.  The operator helps maintain a level



 continuity.

That's nice to know, ;), but you've not addressed my porting issue. Do


 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



 ==/!= be preserved. The compiler does *nothing* to help, since it's


 happy with the syntax if you forget/omit the extra "=" - it all




 compiles. Who knows when these erroneous constructs will bite at


 The first time it's run? After 1,000,000 executions? It's the Turing

 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"



 "is
 not", but I'm not particularly stuck on that. Anything that will




 these
 errors.

 The only alternative that will save us from unknown numbers of




 is
 to
 proscribe all porting and require everything to be written anew.



 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie




Oct 11 2003
next sibling parent reply "Charles Sanders" <sanders-consulting comcast.net> writes:
 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

 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

 not creep into arbitrarily large amounts of ported code, since one

 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%

 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

 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

 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

 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

 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

 Is this clear? If it's not, I'll try again, because this is so important

 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 ?

 I havent done any real porting so I dont have much of an argument other

 i think its 'purtier' than "is" ( although I am working with Y. Tomino


 get win32.lib easy to use, requiring alot of .def files and exports to


 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


 prefer if == and != could do the same thing, but if not I would much

 have an operator than 'is [of]'.  The operator helps maintain a




 of
 continuity.

That's nice to know, ;), but you've not addressed my porting issue. Do


 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





 translating ==/!= to ===/!==, whereas doing it for other types



 ==/!= be preserved. The compiler does *nothing* to help, since





 quite
 happy with the syntax if you forget/omit the extra "=" - it all




 compiles. Who knows when these erroneous constructs will bite at


 The first time it's run? After 1,000,000 executions? It's the





 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





 facilitate undetectable errors entering code? My suggestion is





 and
 "is
 not", but I'm not particularly stuck on that. Anything that will




 these
 errors.

 The only alternative that will save us from unknown numbers of




 is
 to
 proscribe all porting and require everything to be written anew.



 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie





Oct 11 2003
next sibling parent "Charles Sanders" <sanders-consulting comcast.net> writes:
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

 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

 the translation of != and == to !== and === can be overlooked, and the
 compiler does nothing to help. Since porting code will feature large,


 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

 not creep into arbitrarily large amounts of ported code, since one

 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


 not recognised in D
 - Change all the pointers to D references - this is 100%

 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

 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

 change the first one, and not the second one. In the two cases above, if


 make no change to these operators the compiler is happy. However, the

 conditional now has a runtime error waiting to kill the process. This


 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

 land. People will rightly say that D has fostered entirely new methods


 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

 Is this clear? If it's not, I'll try again, because this is so important

 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



 code in extern () blocks that the pointer comparison has to be



 changed to === and !== , and that this causes a bunch of errors ?

 I havent done any real porting so I dont have much of an argument



 than
 i think its 'purtier' than "is" ( although I am working with Y. Tomino


 get win32.lib easy to use, requiring alot of .def files and exports to


 it to work.  Right now the only way I can see to do it is for each



 ,
 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 === .





 would
 prefer if == and != could do the same thing, but if not I would





 rather
 have an operator than 'is [of]'.  The operator helps maintain a




 of
 continuity.

That's nice to know, ;), but you've not addressed my porting issue.




 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





 translating ==/!= to ===/!==, whereas doing it for other types



 ==/!= be preserved. The compiler does *nothing* to help, since





 quite
 happy with the syntax if you forget/omit the extra "=" - it all




 compiles. Who knows when these erroneous constructs will bite at


 The first time it's run? After 1,000,000 executions? It's the





 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





 facilitate undetectable errors entering code? My suggestion is





 and
 "is
 not", but I'm not particularly stuck on that. Anything that will




 these
 errors.

 The only alternative that will save us from unknown numbers of




 is
 to
 proscribe all porting and require everything to be written anew.



 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie






Oct 11 2003
prev sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
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

 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

 the translation of != and == to !== and === can be overlooked, and the
 compiler does nothing to help. Since porting code will feature large,


 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

 not creep into arbitrarily large amounts of ported code, since one

 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


 not recognised in D
 - Change all the pointers to D references - this is 100%

 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

 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

 change the first one, and not the second one. In the two cases above, if


 make no change to these operators the compiler is happy. However, the

 conditional now has a runtime error waiting to kill the process. This


 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

 land. People will rightly say that D has fostered entirely new methods


 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

 Is this clear? If it's not, I'll try again, because this is so important

 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



 code in extern () blocks that the pointer comparison has to be



 changed to === and !== , and that this causes a bunch of errors ?

 I havent done any real porting so I dont have much of an argument



 than
 i think its 'purtier' than "is" ( although I am working with Y. Tomino


 get win32.lib easy to use, requiring alot of .def files and exports to


 it to work.  Right now the only way I can see to do it is for each



 ,
 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 === .





 would
 prefer if == and != could do the same thing, but if not I would





 rather
 have an operator than 'is [of]'.  The operator helps maintain a




 of
 continuity.

That's nice to know, ;), but you've not addressed my porting issue.




 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





 translating ==/!= to ===/!==, whereas doing it for other types



 ==/!= be preserved. The compiler does *nothing* to help, since





 quite
 happy with the syntax if you forget/omit the extra "=" - it all




 compiles. Who knows when these erroneous constructs will bite at


 The first time it's run? After 1,000,000 executions? It's the





 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





 facilitate undetectable errors entering code? My suggestion is





 and
 "is
 not", but I'm not particularly stuck on that. Anything that will




 these
 errors.

 The only alternative that will save us from unknown numbers of




 is
 to
 proscribe all porting and require everything to be written anew.



 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie






Oct 11 2003
prev sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
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

 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

 not creep into arbitrarily large amounts of ported code, since one

 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%

 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

 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

 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

 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

 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

 Is this clear? If it's not, I'll try again, because this is so important

 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 ?

 I havent done any real porting so I dont have much of an argument other

 i think its 'purtier' than "is" ( although I am working with Y. Tomino


 get win32.lib easy to use, requiring alot of .def files and exports to


 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


 prefer if == and != could do the same thing, but if not I would much

 have an operator than 'is [of]'.  The operator helps maintain a




 of
 continuity.

That's nice to know, ;), but you've not addressed my porting issue. Do


 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





 translating ==/!= to ===/!==, whereas doing it for other types



 ==/!= be preserved. The compiler does *nothing* to help, since





 quite
 happy with the syntax if you forget/omit the extra "=" - it all




 compiles. Who knows when these erroneous constructs will bite at


 The first time it's run? After 1,000,000 executions? It's the





 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





 facilitate undetectable errors entering code? My suggestion is





 and
 "is
 not", but I'm not particularly stuck on that. Anything that will




 these
 errors.

 The only alternative that will save us from unknown numbers of




 is
 to
 proscribe all porting and require everything to be written anew.



 of
 myriad potential doors slamming ...)

 Yours portentously

 Freddie





Oct 12 2003
parent "Hauke Duden" <H.NS.Duden gmx.net> writes:
"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"

 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
Oct 12 2003
prev sibling parent reply Patrick Down <pat codemoon.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in
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

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'.
Oct 11 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns94119FB75D346patcodemooncom 63.105.9.61...
 "Matthew Wilson" <matthew stlsoft.org> wrote in
 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

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 ...
Oct 11 2003
next sibling parent "Vathix" <vathix dprogramming.com> writes:
 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.
Oct 11 2003
prev sibling parent Patrick Down <pat codemoon.com> writes:
"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.
Oct 12 2003