"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b65slq$r40$1@digitaldaemon.com...

> 2. I would like to stipulate that I wasn't calling any person stupid, or seeking to imply that anyone is. I often comment that certain things are stupid, but _never_ personalise things, especially on a Digital Mars
group.
> ;) That's just plain bad manners.

guilty as charged.

Sorry, I'm very emotional about this but not nearly as eloquent as you.

> mean, when s is an iostream input stream instance? I don't know! Every
time
> I see such thing I have to run to see whether operator void *() means
> good(), or not bad(), or not eof(), or not eof() AND not bad(), or blah
blah
> blah all the way back to the drawing board. Heaven's above, if having operator void *() used to denote a boolean state doesn't get people's
alarm
> bells ringing, I'm going to take up ornate pastry making, and leave this game to those who clearly grok a picture my feeble brain can never hope to comprehend!

They so should have chosen to just overload operator bool() instead.  I
don't get why they chose to overload operator void*()... that's just
silliness!  Maybe it was to prevent the kind of use such as

if (stream == true) {}

> I'm primarily a coper, rather than an idealist, so if Walter'll give me
the
> compiler switch to warn of non-boolean conditional expressions, I'll
promise
> never to darken the door of this subject again. Over to you, big W ...

Walter will probably never add a warning switch to D... he has always been against them to my knowledge.

Sean

I was going to say that I am *not* against this sort of thing, but as I was typing it out, I realized that I would probably hate this behavior myself if it happened.

For one thing, the compiler is changing all your nice terse code into long-winded explicit code.  Now when you want to maintain it you have to deal with the long version.

For another, everytime you compile your editor will have to reload the changes.  If you were making changes while you were compiling, you could be in big trouble.

Perhaps there could be a compiler switch that told the compiler to 'pretty up' the source as it goes.  Maintenance coders would like it.  In fact the compiler wouldn't have to have such a thing;  D is easy enough to parse that it would be easy for a 3rd party guy to make such a cleanup tool.

Sean


"Antti Sykari" <jsykari@gamma.hut.fi> wrote in message news:87vfy1krgi.fsf_-_@hoastest1-8c.hoasnet.inet.fi...
> "Matthew Wilson" <dmd@synesis.com.au> writes:
>
> > habit, and it does not impede the speed of my development; I still write code _very_ quickly, but more safely and, as I emphasised before, much
more
> > *maintainably*. That's the important part of it.
>
> You're quite on the right track when talking about maintainability.
>
> When you encounter the line
>
>   if (hilavitkutin != null)
>
> you indeed know instantly that hilavitkutin is a reference type.  And when you see
>
>   if (kalapala != 0)
>
> it's perfectly clear that the variable is an integer one, not to mention things like
>
>   if (!some_input_stream.eof())
>
> So this kind of verbosity should be definitely encouraged in code that is to be read by someone.
>
> But the compiler (or IDE, or whatever) has the access to the type information, so why doesn't it transform to less readable, terse code to more readable and maintainable code automatically, as a side effect of the compilation?  Why must the burden of annotating the code with redundant information be left to the programmer?
>
> Suppose that you have file test.d (and also suppose that if (o) was
> legal) and you compile it:
>
> test.d (before compilation):
>
> void f(Object o)
> {
>   if (o)
>     use(o);
> }
>
> then you compile it -- execute yourfancydcompiler test.d -- and it changes copies test.d to test.d.orig and makes a new test.d:
>
> test.d (after compilation):
>
> void f(Object o)
> {
>   if (o != null)
>     use(o);
> }
>
> It's the small things that make the perfect development environment, right?
>
> -Antti

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b67hji$1sh4$1@digitaldaemon.com...
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b65slq$r40$1@digitaldaemon.com...
>
> > 2. I would like to stipulate that I wasn't calling any person stupid, or seeking to imply that anyone is. I often comment that certain things are stupid, but _never_ personalise things, especially on a Digital Mars
> group.
> > ;) That's just plain bad manners.
>
> guilty as charged.
>
> Sorry, I'm very emotional about this but not nearly as eloquent as you.
>

History.

& thanks for compliment, I think. ;)


> > mean, when s is an iostream input stream instance? I don't know! Every
> time
> > I see such thing I have to run to see whether operator void *() means
> > good(), or not bad(), or not eof(), or not eof() AND not bad(), or blah
> blah
> > blah all the way back to the drawing board. Heaven's above, if having operator void *() used to denote a boolean state doesn't get people's
> alarm
> > bells ringing, I'm going to take up ornate pastry making, and leave this game to those who clearly grok a picture my feeble brain can never hope
to
> > comprehend!
>
> They so should have chosen to just overload operator bool() instead.  I
> don't get why they chose to overload operator void*()... that's just
> silliness!  Maybe it was to prevent the kind of use such as
>
> if (stream == true) {}
>

Well, I know why. It was because operator bool did not exist at that time, because bool didn't exist until C++98. However, even with operator bool() we would still have the confusion as to what it meant?

> > I'm primarily a coper, rather than an idealist, so if Walter'll give me
> the
> > compiler switch to warn of non-boolean conditional expressions, I'll
> promise
> > never to darken the door of this subject again. Over to you, big W ...
>
> Walter will probably never add a warning switch to D... he has always been against them to my knowledge.

Then I must sadly restake my assertion that we must enforce bool conditionals. (Frankly I'd prefer the warning and avoid the fight.)

>
> Sean
>
>

Sounds like an exciting idea, but it'd make a nightmare of make and source code control. :(

"Antti Sykari" <jsykari@gamma.hut.fi> wrote in message news:87vfy1krgi.fsf_-_@hoastest1-8c.hoasnet.inet.fi...
> "Matthew Wilson" <dmd@synesis.com.au> writes:
>
> > habit, and it does not impede the speed of my development; I still write code _very_ quickly, but more safely and, as I emphasised before, much
more
> > *maintainably*. That's the important part of it.
>
> You're quite on the right track when talking about maintainability.
>
> When you encounter the line
>
>   if (hilavitkutin != null)
>
> you indeed know instantly that hilavitkutin is a reference type.  And when you see
>
>   if (kalapala != 0)
>
> it's perfectly clear that the variable is an integer one, not to mention things like
>
>   if (!some_input_stream.eof())
>
> So this kind of verbosity should be definitely encouraged in code that is to be read by someone.
>
> But the compiler (or IDE, or whatever) has the access to the type information, so why doesn't it transform to less readable, terse code to more readable and maintainable code automatically, as a side effect of the compilation?  Why must the burden of annotating the code with redundant information be left to the programmer?
>
> Suppose that you have file test.d (and also suppose that if (o) was
> legal) and you compile it:
>
> test.d (before compilation):
>
> void f(Object o)
> {
>   if (o)
>     use(o);
> }
>
> then you compile it -- execute yourfancydcompiler test.d -- and it changes copies test.d to test.d.orig and makes a new test.d:
>
> test.d (after compilation):
>
> void f(Object o)
> {
>   if (o != null)
>     use(o);
> }
>
> It's the small things that make the perfect development environment, right?
>
> -Antti

Please not !! !!!! This is the scourge of so called, and almost always self-styled, C++ "gurus". (Of course, this was me in a few of my former programming lives.)

I am encouraged, however, by everyone's willingness to discuss this topic, and think that maybe we can get somewhere. (See new post.)

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b67h67$1s59$1@digitaldaemon.com...
> Perhaps what is needed is an explicit conversion to bool, or an explicit nonzero / non-null check.
>
> Wait, we already have it!  It's called '!!'.
>
> Object o = someobj;
> if (!!o)
> {
>     o.Print();
> }
>
> If you want to disallow implicit conversion to bool, at least keep the '!' operator so we can do this trick, which is still terse, yet explicit.  I argue that it's *not* that hard to read.  Once you've seen it once you
will
> know the idiom.
>
> Unless someone has an idea for another operator that means explicit check
if
> non-null?
>
> I'm not that against some other statement construct for this purpose, either:
>
> if_valid(o)
> {
> }
>
> Or perhaps this behavior could be made part of the 'with' statement:
>
> with(o)  // skips the whole block if o is null
> {
> }
>
> Sean
>
>
>
> "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b65qho$pqk$1@digitaldaemon.com...
> > Since the vast bulk of my experience is C & C++, I am coming from that perspective (where implicit conversions are both easy and nasty). My experience (and I have a lot of it in terms of clearing up other
people's
> > messes) informs me that both these languages should follow Java's lead
in
> > the boolean-ness of conditional expressions. I do this myself as a
matter
> of
> > habit, and it does not impede the speed of my development; I still write code _very_ quickly, but more safely and, as I emphasised before, much
> more
> > *maintainably*. That's the important part of it.
> >
> > To the degree we are discussing it, terseness is an irrelevance. What matters is correctness, clarity  and maintainability. People with a lot
> more
> > weight and "name" in the industry than little old me have documented war stories up to their armpit. I mean no discourtesy to you (or anyone else
> who
> > espouses your point of view), but I find that programmers who do, or
have
> > done, a lot of maintenance and/or trouble-shooting & remediation are unaninmous in their willingness to sacrifice terseness (not to mention
the
> > odd right arm) for correctness, clarity and maintainability.
> >
> > I am a little surprised that a language that seeks to make it hard to do
> the
> > hard mistakes of other languages, and makes it impossible to do the
simple
> > mistakes, passes the book on this point. I'm not advocating a nannying language, such as Java - printf() is well worth the risk - but boolean conditionals seems to be such a good reward for such a little sacrifice.
> >
> > However, we are debating needlessly. I know full well that I've got more chance of persuading Microsoft to write a standards-compliant Java
> compiler
> > than I have in persuading the vast bulk of developers to accept extra
> typing
> > when they deem it's not needed.
> >
> > To satisfy everyone, perhaps all we need is an optional compiler
warning -
> > in the
> > vein of DMC++s -wc - that tells us about it. (And the ability to promote
> it
> > to an error, of course). Walter, I imagine this would be pretty easy to
> do?
> >
> > "Luna Kid" <lunakid@neuropolis.org> wrote in message news:b64rc4$4m3$1@digitaldaemon.com...
> > > > > Wouldn't you normally write ?:
> > > > > if (obj) {}
> > > > > if (!obj) {}
> > > >
> > > > No. Absolutely not. Here is something that C# and D have done that
is
> > far
> > > > better than C and C++ (and, I think, D). The expressions in
> conditionals
> > > > should be explicitly boolean. Hence
> > > >
> > > > int    i = 1;
> > > > X    x = new X();
> > > >
> > > > if(i)
> > > > {
> > > >
> > > > if(!x)
> > > > {
> > > >
> > > > Neither of those are sensible syntax. They are pandering to the
> > ludicrous
> > > > proposition that the extra typing to get to ...
> > >
> > >
> > >
> > > Well, apart from it *being* sensible syntax (e.g. when x is boolean), I'd like to stress another point.
> > >
> > > Terseness is a very valid and important goal - it is one of
> > > the most important properties of an all-around language. Some
> > > of it should, naturally, be traded off for other valid goals,
> > > like readability (see PERL for a bad-balance example, or Eiffel,
> > > on the "too verbose" end to some).
> > >
> > > Since
> > >
> > >         if (x is initialized)
> > >
> > >             do something with x
> > >
> > >         else
> > >
> > >             do error handling
> > >
> > > is among the most common coding idioms, one cannot ignore the relief the short if (x) form gives to one's fingers. It's not at all just an unfortunate accident that the syntax allows it in so many practical languages - instead, the opposite is true: the support is well worse the risks.
> > >
> > > However, it is also true, that there could be much better ways to support that idiom, than tweaked "if" statements...
> > >
> > > Using e.g. exception handling (in languages where it's convenient to use) the above can be rewritten to something like:
> > >
> > >         try
> > >
> > >             something with x
> > >
> > >         else if (x is not initialized)    // "catch"
> > >
> > >             do error handling
> > >
> > > Exceptions, however, are practical only for heavier cases,
> > > where e.g. errors can arise at multiple points etc. Exceptions
> > > are *not* optimal (both in terms of readability and efficiency)
> > > for the simplest and (therefore?) most frequent cases, where
> > > a single "if" would also do perfectly.
> > >
> > > So
> > >     - for the very frequent simple cases exceptions give you
> > >       nothing but unnecessary overhead
> > >
> > >     - legacy code will be never rewritten from
> > >
> > >                 "if (x is initialized)"
> > >       to
> > >                 "catch (x is not initialized)"
> > >
> > >       in order to use exception handling just because it's
> > >       available and is considered "modern style"
> > >
> > > DbC invariant would also be much better, but they are just impossible, or non-trivial, or too much work to add for simple, built-in types.
> > >
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >
> > > About initializations....
> > >
> > > In short: practice sadly blurs the two completely different concepts, but "being zero" is NOT THE SAME THING as "being uninitialized". (But I guess most of you are well aware of this classic problem of automatic zero-init.) Even, "being uninitialized because of a bug" or "not got a valid value by run-time input" are two subtly different things.
> > >
> > > Now, unfortunately, as the "ideal language" is still yet to be defined, there is no standard, clear and explicit notation for
> > >
> > >         if (initialized x)
> > >
> > >             do something with x
> > >
> > >         else
> > >
> > >             do error handling
> > >
> > > programmers, when handling the above-mentioned different cases, fall back "randomly" to various techniques available in the language they usewith whatever available (some form of an "if" caluse, exception handling, assertions or other invariant checking (DbC stuff) etc.).
> > >
> > > Some languages - implicitly - support this fallback (e.g. with
> > > imlicit conversion to bool and supporting the short if(x) form),
> > > some others pretend as if the need to express briefly that
> > > "if x is OK" never existed in the real world, forcing the
> > > fallback more painful than necessary (e.g. by saying "use
> > > exceptions" or "compare x to some value" or "define an
> > > is_initialized() boolean function").
> > >
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >
> > > So, to sum it up... The "Right Thing" for coding the simple and very frequent case of "checking the usability of an object before use" would be *explicitly* supported by a good language, in some dedicated way. The "ideal language" would acknowledge that objects tend to be in "usable" and "unusable" states.
> > >
> > > It would go further than silently encouraging programmers
> > > writing "if (x)"...
> > >
> > > Thanks,
> > > Luna Kid
> > >
> > >
> >
> >
>
>

Matt,

> What does
>
>  string  line;
>
>  while(s >> line)
>
> mean, when s is an iostream input stream instance? I don't know!

  (I must say I like these 7 lines of a good example
  much better than "pontifications" of any length...)

> cannot believe that <...> the same experienced practitioners have not been bitten by the meaning of implicit conversion operators.

  In the other thread ("Re: Identity & equivalence") I expressed
  my (quite similar) stance on this:

> > ...  And "if (object)" would automatically convert the object
> > to bool.
> >
> > And by the way, I'd just *love* to have other user-defined conversions between different types as well.
> >
> > (Maybe this is asking too much - perhaps it's better to stop before the language starts to approach C++ in complexity, right?)
> >
> > -Antti
>
> Some of it *is* practical. All of it, unleashed, leads
> to horror you can see in C++.

  What I only dream of now, is just operator bool()...

Cheers,
Luna Kid

I have to second, what Matt said.

Sean,

> > Perhaps what is needed is an explicit conversion to bool,

It should read:

> > Perhaps what is needed is an explicit conversion to bool.

;)

Cheers,
Luna Kid



"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b67ol6$21nu$1@digitaldaemon.com...
> Please not !! !!!! This is the scourge of so called, and almost always self-styled, C++ "gurus". (Of course, this was me in a few of my former programming lives.)
>
> I am encouraged, however, by everyone's willingness to discuss this topic, and think that maybe we can get somewhere. (See new post.)
>
> "Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b67h67$1s59$1@digitaldaemon.com...
> > Perhaps what is needed is an explicit conversion to bool, or an explicit nonzero / non-null check.
> >
> > Wait, we already have it!  It's called '!!'.
> >
> > Object o = someobj;
> > if (!!o)
> > {
> >     o.Print();
> > }
> >
> > If you want to disallow implicit conversion to bool, at least keep the
'!'
> > operator so we can do this trick, which is still terse, yet explicit.  I argue that it's *not* that hard to read.  Once you've seen it once you
> will
> > know the idiom.
> >
> > Unless someone has an idea for another operator that means explicit
check
> if
> > non-null?
> >
> > I'm not that against some other statement construct for this purpose, either:
> >
> > if_valid(o)
> > {
> > }
> >
> > Or perhaps this behavior could be made part of the 'with' statement:
> >
> > with(o)  // skips the whole block if o is null
> > {
> > }
> >
> > Sean
> >
> >
> >
> > "Matthew Wilson" <dmd@synesis.com.au> wrote in message news:b65qho$pqk$1@digitaldaemon.com...
> > > Since the vast bulk of my experience is C & C++, I am coming from that perspective (where implicit conversions are both easy and nasty). My experience (and I have a lot of it in terms of clearing up other
> people's
> > > messes) informs me that both these languages should follow Java's lead
> in
> > > the boolean-ness of conditional expressions. I do this myself as a
> matter
> > of
> > > habit, and it does not impede the speed of my development; I still
write
> > > code _very_ quickly, but more safely and, as I emphasised before, much
> > more
> > > *maintainably*. That's the important part of it.
> > >
> > > To the degree we are discussing it, terseness is an irrelevance. What matters is correctness, clarity  and maintainability. People with a
lot
> > more
> > > weight and "name" in the industry than little old me have documented
war
> > > stories up to their armpit. I mean no discourtesy to you (or anyone
else
> > who
> > > espouses your point of view), but I find that programmers who do, or
> have
> > > done, a lot of maintenance and/or trouble-shooting & remediation are unaninmous in their willingness to sacrifice terseness (not to mention
> the
> > > odd right arm) for correctness, clarity and maintainability.
> > >
> > > I am a little surprised that a language that seeks to make it hard to
do
> > the
> > > hard mistakes of other languages, and makes it impossible to do the
> simple
> > > mistakes, passes the book on this point. I'm not advocating a nannying language, such as Java - printf() is well worth the risk - but boolean conditionals seems to be such a good reward for such a little
sacrifice.
> > >
> > > However, we are debating needlessly. I know full well that I've got
more
> > > chance of persuading Microsoft to write a standards-compliant Java
> > compiler
> > > than I have in persuading the vast bulk of developers to accept extra
> > typing
> > > when they deem it's not needed.
> > >
> > > To satisfy everyone, perhaps all we need is an optional compiler
> warning -
> > > in the
> > > vein of DMC++s -wc - that tells us about it. (And the ability to
promote
> > it
> > > to an error, of course). Walter, I imagine this would be pretty easy
to
> > do?
> > >
> > > "Luna Kid" <lunakid@neuropolis.org> wrote in message news:b64rc4$4m3$1@digitaldaemon.com...
> > > > > > Wouldn't you normally write ?:
> > > > > > if (obj) {}
> > > > > > if (!obj) {}
> > > > >
> > > > > No. Absolutely not. Here is something that C# and D have done that
> is
> > > far
> > > > > better than C and C++ (and, I think, D). The expressions in
> > conditionals
> > > > > should be explicitly boolean. Hence
> > > > >
> > > > > int    i = 1;
> > > > > X    x = new X();
> > > > >
> > > > > if(i)
> > > > > {
> > > > >
> > > > > if(!x)
> > > > > {
> > > > >
> > > > > Neither of those are sensible syntax. They are pandering to the
> > > ludicrous
> > > > > proposition that the extra typing to get to ...
> > > >
> > > >
> > > >
> > > > Well, apart from it *being* sensible syntax (e.g. when x is boolean), I'd like to stress another point.
> > > >
> > > > Terseness is a very valid and important goal - it is one of
> > > > the most important properties of an all-around language. Some
> > > > of it should, naturally, be traded off for other valid goals,
> > > > like readability (see PERL for a bad-balance example, or Eiffel,
> > > > on the "too verbose" end to some).
> > > >
> > > > Since
> > > >
> > > >         if (x is initialized)
> > > >
> > > >             do something with x
> > > >
> > > >         else
> > > >
> > > >             do error handling
> > > >
> > > > is among the most common coding idioms, one cannot ignore the relief the short if (x) form gives to one's fingers. It's not at all just an unfortunate accident that the syntax allows it in so many practical languages - instead, the opposite is true: the support is well worse the risks.
> > > >
> > > > However, it is also true, that there could be much better ways to support that idiom, than tweaked "if" statements...
> > > >
> > > > Using e.g. exception handling (in languages where it's convenient to use) the above can be rewritten to something like:
> > > >
> > > >         try
> > > >
> > > >             something with x
> > > >
> > > >         else if (x is not initialized)    // "catch"
> > > >
> > > >             do error handling
> > > >
> > > > Exceptions, however, are practical only for heavier cases,
> > > > where e.g. errors can arise at multiple points etc. Exceptions
> > > > are *not* optimal (both in terms of readability and efficiency)
> > > > for the simplest and (therefore?) most frequent cases, where
> > > > a single "if" would also do perfectly.
> > > >
> > > > So
> > > >     - for the very frequent simple cases exceptions give you
> > > >       nothing but unnecessary overhead
> > > >
> > > >     - legacy code will be never rewritten from
> > > >
> > > >                 "if (x is initialized)"
> > > >       to
> > > >                 "catch (x is not initialized)"
> > > >
> > > >       in order to use exception handling just because it's
> > > >       available and is considered "modern style"
> > > >
> > > > DbC invariant would also be much better, but they are just impossible, or non-trivial, or too much work to add for simple, built-in types.
> > > >
> > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > >
> > > > About initializations....
> > > >
> > > > In short: practice sadly blurs the two completely different concepts, but "being zero" is NOT THE SAME THING as "being uninitialized". (But I guess most of you are well aware of this classic problem of automatic zero-init.) Even, "being uninitialized because of a bug" or "not got a valid value by run-time input" are two subtly different things.
> > > >
> > > > Now, unfortunately, as the "ideal language" is still yet to be defined, there is no standard, clear and explicit notation for
> > > >
> > > >         if (initialized x)
> > > >
> > > >             do something with x
> > > >
> > > >         else
> > > >
> > > >             do error handling
> > > >
> > > > programmers, when handling the above-mentioned different cases, fall back "randomly" to various techniques available in the language they usewith whatever available (some form of an "if" caluse, exception handling, assertions or other invariant checking (DbC stuff) etc.).
> > > >
> > > > Some languages - implicitly - support this fallback (e.g. with
> > > > imlicit conversion to bool and supporting the short if(x) form),
> > > > some others pretend as if the need to express briefly that
> > > > "if x is OK" never existed in the real world, forcing the
> > > > fallback more painful than necessary (e.g. by saying "use
> > > > exceptions" or "compare x to some value" or "define an
> > > > is_initialized() boolean function").
> > > >
> > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > >
> > > > So, to sum it up... The "Right Thing" for coding the simple and very frequent case of "checking the usability of an object before use" would be *explicitly* supported by a good language, in some dedicated way. The "ideal language" would acknowledge that objects tend to be in "usable" and "unusable" states.
> > > >
> > > > It would go further than silently encouraging programmers
> > > > writing "if (x)"...
> > > >
> > > > Thanks,
> > > > Luna Kid
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Pedant!  ;)

Sean

"Luna Kid" <lunakid@neuropolis.org> wrote in message news:b67ppn$22jn$1@digitaldaemon.com...
> I have to second, what Matt said.
>
> Sean,
>
> > > Perhaps what is needed is an explicit conversion to bool,
>
> It should read:
>
> > > Perhaps what is needed is an explicit conversion to bool.
>
> ;)
>
> Cheers,
> Luna Kid

Hi, Matthew.

I'll second the desire for a real boolean in the condition.  However, it would go against Walter's goal of reducing the speed bumps in converting from C++ to D.

Your idea of a compiler warning sounds like an excellent compromise to me.  I'd certainly use it.

Bill

Matthew Wilson wrote:
> Since the vast bulk of my experience is C & C++, I am coming from that
> perspective (where implicit conversions are both easy and nasty). My
> experience (and I have a lot of it in terms of clearing up other people's
> messes) informs me that both these languages should follow Java's lead in
> the boolean-ness of conditional expressions. I do this myself as a matter of
> habit, and it does not impede the speed of my development; I still write
> code _very_ quickly, but more safely and, as I emphasised before, much more
> *maintainably*. That's the important part of it.
> 
> To the degree we are discussing it, terseness is an irrelevance. What
> matters is correctness, clarity  and maintainability. People with a lot more
> weight and "name" in the industry than little old me have documented war
> stories up to their armpit. I mean no discourtesy to you (or anyone else who
> espouses your point of view), but I find that programmers who do, or have
> done, a lot of maintenance and/or trouble-shooting & remediation are
> unaninmous in their willingness to sacrifice terseness (not to mention the
> odd right arm) for correctness, clarity and maintainability.
> 
> I am a little surprised that a language that seeks to make it hard to do the
> hard mistakes of other languages, and makes it impossible to do the simple
> mistakes, passes the book on this point. I'm not advocating a nannying
> language, such as Java - printf() is well worth the risk - but boolean
> conditionals seems to be such a good reward for such a little sacrifice.
> 
> However, we are debating needlessly. I know full well that I've got more
> chance of persuading Microsoft to write a standards-compliant Java compiler
> than I have in persuading the vast bulk of developers to accept extra typing
> when they deem it's not needed.
> 
> To satisfy everyone, perhaps all we need is an optional compiler warning -
> in the
> vein of DMC++s -wc - that tells us about it. (And the ability to promote it
> to an error, of course). Walter, I imagine this would be pretty easy to do?
> 
> "Luna Kid" <lunakid@neuropolis.org> wrote in message
> news:b64rc4$4m3$1@digitaldaemon.com...
> 
>>>>Wouldn't you normally write ?:
>>>>if (obj) {}
>>>>if (!obj) {}
>>>
>>>No. Absolutely not. Here is something that C# and D have done that is
>>
> far
> 
>>>better than C and C++ (and, I think, D). The expressions in conditionals
>>>should be explicitly boolean. Hence
>>>
>>>int    i = 1;
>>>X    x = new X();
>>>
>>>if(i)
>>>{
>>>
>>>if(!x)
>>>{
>>>
>>>Neither of those are sensible syntax. They are pandering to the
>>
> ludicrous
> 
>>>proposition that the extra typing to get to ...
>>
>>
>>
>>Well, apart from it *being* sensible syntax (e.g. when x is
>>boolean), I'd like to stress another point.
>>
>>Terseness is a very valid and important goal - it is one of
>>the most important properties of an all-around language. Some
>>of it should, naturally, be traded off for other valid goals,
>>like readability (see PERL for a bad-balance example, or Eiffel,
>>on the "too verbose" end to some).
>>
>>Since
>>
>>        if (x is initialized)
>>
>>            do something with x
>>
>>        else
>>
>>            do error handling
>>
>>is among the most common coding idioms, one cannot ignore
>>the relief the short if (x) form gives to one's fingers.
>>It's not at all just an unfortunate accident that the syntax
>>allows it in so many practical languages - instead, the
>>opposite is true: the support is well worse the risks.
>>
>>However, it is also true, that there could be much better
>>ways to support that idiom, than tweaked "if" statements...
>>
>>Using e.g. exception handling (in languages where it's
>>convenient to use) the above can be rewritten to something
>>like:
>>
>>        try
>>
>>            something with x
>>
>>        else if (x is not initialized)    // "catch"
>>
>>            do error handling
>>
>>Exceptions, however, are practical only for heavier cases,
>>where e.g. errors can arise at multiple points etc. Exceptions
>>are *not* optimal (both in terms of readability and efficiency)
>>for the simplest and (therefore?) most frequent cases, where
>>a single "if" would also do perfectly.
>>
>>So
>>    - for the very frequent simple cases exceptions give you
>>      nothing but unnecessary overhead
>>
>>    - legacy code will be never rewritten from
>>
>>                "if (x is initialized)"
>>      to
>>                "catch (x is not initialized)"
>>
>>      in order to use exception handling just because it's
>>      available and is considered "modern style"
>>
>>DbC invariant would also be much better, but they are just
>>impossible, or non-trivial, or too much work to add for
>>simple, built-in types.
>>
>>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>About initializations....
>>
>>In short: practice sadly blurs the two completely different
>>concepts, but "being zero" is NOT THE SAME THING as "being
>>uninitialized". (But I guess most of you are well aware of
>>this classic problem of automatic zero-init.) Even, "being
>>uninitialized because of a bug" or "not got a valid value
>>by run-time input" are two subtly different things.
>>
>>Now, unfortunately, as the "ideal language" is still yet to
>>be defined, there is no standard, clear and explicit notation
>>for
>>
>>        if (initialized x)
>>
>>            do something with x
>>
>>        else
>>
>>            do error handling
>>
>>programmers, when handling the above-mentioned different cases,
>>fall back "randomly" to various techniques available in the
>>language they usewith whatever available (some form of an "if"
>>caluse, exception handling, assertions or other invariant checking
>>(DbC stuff) etc.).
>>
>>Some languages - implicitly - support this fallback (e.g. with
>>imlicit conversion to bool and supporting the short if(x) form),
>>some others pretend as if the need to express briefly that
>>"if x is OK" never existed in the real world, forcing the
>>fallback more painful than necessary (e.g. by saying "use
>>exceptions" or "compare x to some value" or "define an
>>is_initialized() boolean function").
>>
>>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>So, to sum it up... The "Right Thing" for coding the simple
>>and very frequent case of "checking the usability of an object
>>before use" would be *explicitly* supported by a good language,
>>in some dedicated way. The "ideal language" would acknowledge
>>that objects tend to be in "usable" and "unusable" states.
>>
>>It would go further than silently encouraging programmers
>>writing "if (x)"...
>>
>>Thanks,
>>Luna Kid
>>
>>
> 
> 
> 

Good to hear. Reckon we'll get Walter to put it in? :)

"Bill Cox" <bill@viasic.com> wrote in message news:3E87F9DF.9090002@viasic.com...
> Hi, Matthew.
>
> I'll second the desire for a real boolean in the condition.  However, it would go against Walter's goal of reducing the speed bumps in converting from C++ to D.
>
> Your idea of a compiler warning sounds like an excellent compromise to me.  I'd certainly use it.
>
> Bill
>
> Matthew Wilson wrote:
> > Since the vast bulk of my experience is C & C++, I am coming from that perspective (where implicit conversions are both easy and nasty). My experience (and I have a lot of it in terms of clearing up other
people's
> > messes) informs me that both these languages should follow Java's lead
in
> > the boolean-ness of conditional expressions. I do this myself as a
matter of
> > habit, and it does not impede the speed of my development; I still write code _very_ quickly, but more safely and, as I emphasised before, much
more
> > *maintainably*. That's the important part of it.
> >
> > To the degree we are discussing it, terseness is an irrelevance. What matters is correctness, clarity  and maintainability. People with a lot
more
> > weight and "name" in the industry than little old me have documented war stories up to their armpit. I mean no discourtesy to you (or anyone else
who
> > espouses your point of view), but I find that programmers who do, or
have
> > done, a lot of maintenance and/or trouble-shooting & remediation are unaninmous in their willingness to sacrifice terseness (not to mention
the
> > odd right arm) for correctness, clarity and maintainability.
> >
> > I am a little surprised that a language that seeks to make it hard to do
the
> > hard mistakes of other languages, and makes it impossible to do the
simple
> > mistakes, passes the book on this point. I'm not advocating a nannying language, such as Java - printf() is well worth the risk - but boolean conditionals seems to be such a good reward for such a little sacrifice.
> >
> > However, we are debating needlessly. I know full well that I've got more chance of persuading Microsoft to write a standards-compliant Java
compiler
> > than I have in persuading the vast bulk of developers to accept extra
typing
> > when they deem it's not needed.
> >
> > To satisfy everyone, perhaps all we need is an optional compiler
warning -
> > in the
> > vein of DMC++s -wc - that tells us about it. (And the ability to promote
it
> > to an error, of course). Walter, I imagine this would be pretty easy to
do?
> >
> > "Luna Kid" <lunakid@neuropolis.org> wrote in message news:b64rc4$4m3$1@digitaldaemon.com...
> >
> >>>>Wouldn't you normally write ?:
> >>>>if (obj) {}
> >>>>if (!obj) {}
> >>>
> >>>No. Absolutely not. Here is something that C# and D have done that is
> >>
> > far
> >
> >>>better than C and C++ (and, I think, D). The expressions in
conditionals
> >>>should be explicitly boolean. Hence
> >>>
> >>>int    i = 1;
> >>>X    x = new X();
> >>>
> >>>if(i)
> >>>{
> >>>
> >>>if(!x)
> >>>{
> >>>
> >>>Neither of those are sensible syntax. They are pandering to the
> >>
> > ludicrous
> >
> >>>proposition that the extra typing to get to ...
> >>
> >>
> >>
> >>Well, apart from it *being* sensible syntax (e.g. when x is boolean), I'd like to stress another point.
> >>
> >>Terseness is a very valid and important goal - it is one of
> >>the most important properties of an all-around language. Some
> >>of it should, naturally, be traded off for other valid goals,
> >>like readability (see PERL for a bad-balance example, or Eiffel,
> >>on the "too verbose" end to some).
> >>
> >>Since
> >>
> >>        if (x is initialized)
> >>
> >>            do something with x
> >>
> >>        else
> >>
> >>            do error handling
> >>
> >>is among the most common coding idioms, one cannot ignore the relief the short if (x) form gives to one's fingers. It's not at all just an unfortunate accident that the syntax allows it in so many practical languages - instead, the opposite is true: the support is well worse the risks.
> >>
> >>However, it is also true, that there could be much better ways to support that idiom, than tweaked "if" statements...
> >>
> >>Using e.g. exception handling (in languages where it's convenient to use) the above can be rewritten to something like:
> >>
> >>        try
> >>
> >>            something with x
> >>
> >>        else if (x is not initialized)    // "catch"
> >>
> >>            do error handling
> >>
> >>Exceptions, however, are practical only for heavier cases,
> >>where e.g. errors can arise at multiple points etc. Exceptions
> >>are *not* optimal (both in terms of readability and efficiency)
> >>for the simplest and (therefore?) most frequent cases, where
> >>a single "if" would also do perfectly.
> >>
> >>So
> >>    - for the very frequent simple cases exceptions give you
> >>      nothing but unnecessary overhead
> >>
> >>    - legacy code will be never rewritten from
> >>
> >>                "if (x is initialized)"
> >>      to
> >>                "catch (x is not initialized)"
> >>
> >>      in order to use exception handling just because it's
> >>      available and is considered "modern style"
> >>
> >>DbC invariant would also be much better, but they are just impossible, or non-trivial, or too much work to add for simple, built-in types.
> >>
> >>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>
> >>About initializations....
> >>
> >>In short: practice sadly blurs the two completely different concepts, but "being zero" is NOT THE SAME THING as "being uninitialized". (But I guess most of you are well aware of this classic problem of automatic zero-init.) Even, "being uninitialized because of a bug" or "not got a valid value by run-time input" are two subtly different things.
> >>
> >>Now, unfortunately, as the "ideal language" is still yet to be defined, there is no standard, clear and explicit notation for
> >>
> >>        if (initialized x)
> >>
> >>            do something with x
> >>
> >>        else
> >>
> >>            do error handling
> >>
> >>programmers, when handling the above-mentioned different cases, fall back "randomly" to various techniques available in the language they usewith whatever available (some form of an "if" caluse, exception handling, assertions or other invariant checking (DbC stuff) etc.).
> >>
> >>Some languages - implicitly - support this fallback (e.g. with
> >>imlicit conversion to bool and supporting the short if(x) form),
> >>some others pretend as if the need to express briefly that
> >>"if x is OK" never existed in the real world, forcing the
> >>fallback more painful than necessary (e.g. by saying "use
> >>exceptions" or "compare x to some value" or "define an
> >>is_initialized() boolean function").
> >>
> >>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>
> >>So, to sum it up... The "Right Thing" for coding the simple and very frequent case of "checking the usability of an object before use" would be *explicitly* supported by a good language, in some dedicated way. The "ideal language" would acknowledge that objects tend to be in "usable" and "unusable" states.
> >>
> >>It would go further than silently encouraging programmers
> >>writing "if (x)"...
> >>
> >>Thanks,
> >>Luna Kid
> >>
> >>
> >
> >
> >
>