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 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

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

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
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
>
>

"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
> >
> >
>
>

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: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'.

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
> > > >
> > > >
> > >
> > >
> >
> >
>
>

"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 ...

> 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>