dag@control.lth.se (Dag Bruck) writes:

>Programs that use something called "bool" as a number (i.e., with more
>that two distinct values) will break, and deserve to break in my view.

There is a positive side to code breaking:  sometimes bugs can exist in
code that is using integer bools (eg. what happens if you accidentally
use "&" rather than "&&" with that multi-value bool above?).

--
Warwick

In article <CHs903.I1C@microsoft.com> jimad@microsoft.com (Jim Adcock)
writes:

|> In article <KANZE.93Dec6171747@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
|> >In article <2dsbvu$2j6@nic.lth.se> dag@control.lth.se (Dag Bruck)
|> |Seriously, I think that something is needed for the null pointer
|> |constant, too.  People just don't expect 'f( NULL )' to call 'f( int )'
|> |if there is an 'f( char* )' handy.
|> |--

|> However, even if a nil or null keyword or whatever is defined,
|> f(NULL) will continue to call f(int) unless one was able to hunt down
|> and kill all the places in all the header files that C and C++ programmers
|> have defined what they 'know' 'null', 'nil' or 'NULL' means.  Because
|> the preprocessor still gets first shot at screwing things up.
|> Further, you'd have to track down and kill all the C++ files where
|> C++ programmers have used 0 to mean nil because they didn't want
|> to run into problems with C programmers who define NULL to be what
|> they 'know' it to be.

Except that if they have included stddef.h, or any header file that
includes stddef.h, then that is the *only* place that they have
defined NULL.  Any other definition is illegal.

And I suspect that if the standards committee were to say that the
only legal definition of NULL in stddef.h is the new keyword 'nil' (or
'((void*)0)', if we adapt one of the proposed solutions), then
Microsoft (*not* the user) will change its header file.

|> Wanting a solution is not the same as having one.

I think we've got one.  It isn't perfect, but it is acceptable, and a
definite improvement to the status quo.  Sort of like the keyword
'bool'.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <9334420.29185@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>jimad@microsoft.com (Jim Adcock) writes:
|will be *less* conflicts than if every library defines their own
|different boolean type.
|

Again, this argument doesn't depend on them being keywords.  If 'bool'
macros were defined in a bool.h, then 'in the long run' libraries could
equally agree to use the definitions in bool.h.  And in the near run,
programs wouldn't be broken by the introduction of new keywords, changes
in the type system, and the redefinition of fundamental operators.

In article <ABRAHAM.93Dec9152116@verdande.iesd.auc.dk> abraham@iesd.auc.dk (Per Abrahamsen) writes:
>
|>>>>> "Jim" == Jim Adcock <jimad@microsoft.com> writes:
|
|Jim> I disagree with this decision, because with the bidi
|Jim> autoconversion, I don't see where bool buys you much [other than
|Jim> three new keyword conflicts].
|
|- If people actually start using this type instead of inventing their
|own, maintenance will become less confusing.  For example, SunOS 4.1.1
|has 11 definitions of `TRUE' under /usr/include, three of them
|different.

There are 'solutions' less radical than changing the type system
and the types of fundamental operators which could equally accomplish
this same goal of getting future programmers and programs to agree
on 'bool' usages.  Namely the committee could choose to define a
bool.h header.  People who in the future then wanted to follow convention
could #include bool.h.  Old programs would not be affected by this
change.

jimad@microsoft.com (Jim Adcock) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>|will be *less* conflicts than if every library defines their own
>|different boolean type.
>
>Again, this argument doesn't depend on them being keywords.  If 'bool'
>macros were defined in a bool.h, then 'in the long run' libraries could
>equally agree to use the definitions in bool.h.  And in the near run,
>programs wouldn't be broken by the introduction of new keywords, changes
>in the type system, and the redefinition of fundamental operators.

Programs won't be broken by the changes in the type system or the
redefinition of fundamental operators.  They may be broken by the
introduction of new keywords, but they will be easy to fix.
In return, we can overload on bools, we can define conversion to
bool operators, and compilers can give better warnings.
This is a good tradeoff, IMHO.

--
Fergus Henderson |   "People who brook no compromise in programming
   |   languages should program in lambda calculus or
fjh@munta.cs.mu.OZ.AU |   machine language, depending." --Andrew Koenig.

That seems a bit "boolist" (a boolean bigot), What is wrong with
3 (or even more) valued logic, never mind fuzzy logic?

I suppose bool3 would be a more appropriate name, but (without getting
into some pretty hairy stuff) do we not already have a 3 valued
logic in C(++) - 0, !0 and non terminating.

non-termination can be implemented by a VERY void function :-)
What a shame that && and || are not commutative in this logic :-)

--
        John M Kewley

ICL Computers Limited, Wenlock Way, West Gorton, Manchester. M12 5DR
Tel: (+44) 61 223 1301 X2138  Email: jk@fiveg.icl.co.uk or jk@cs.man.ac.uk

jimad@microsoft.com (Jim Adcock) writes:

>In article <2dljos$40v@news.cerf.net> mitek@nic.cerf.net (Mitek Systems) writes:
>|....Meanwhile, the committee is adding keywords left and right.
>|
>|I don't want to reignite the dying embers of the 0 vs. NULL wars, but
>|I would like to point out that the "break old code" argument
>|seems to be pretty meaningless in light of the committee's actions.
>|
>|

>Not a meaningless argument.  In many cases 'fixing' the shortcomings
 ^^^^^^^^^^^^^^^^^^^^^^^^^
Of course you're right--the argument is not *meaningless*.  However, in
light of the fact that code breakage was the only argument I heard
*against* nil, I think that it is a fairly weak one given the arguments
I've seen *for* it.

>of C or C++ means breaking existing code.  When such a possibility
>arises one valid argument is 'but doing so would break existing code!'
>The other valid argument is 'we have to break code in this case to
>fix the language and make forward progress.'  It remains to the committee
>then to decide *which* argument is more important.  In this case I
>guess they decided to quell the critics who complain that C/C++ doesn't
>even have a boolean type.  I disagree with this decision, because with
>the bidi autoconversion, I don't see where bool buys you much [other
>than three new keyword conflicts].

>We need to wait and see the details.  Perhaps this decision can meet your
>needs too:

> FOO* pfoo = false;

>;-)
That's it!

shane
jsm@miteksys.com

In article <1993Dec8.024440.7019@sat.mot.com> hall_j@sat.mot.com (Joseph Hall) writes:
>Seems it was jimad@microsoft.com (Jim Adcock) who said:
>>I don't see where bool buys you much [other than three new keyword conflicts].
>
>Let's see ... is this a complete list?

What follows is the complete list of C++ keywords (as of the end of the
recent X3J16/WG21 meeting in San Jose):

 and
 and_eq
 asm
 auto
 bitand
 bitor
 bool
 break
 case
 catch
 char
 class
 compl
 const
 const_cast
 continue
 default
 delete
 do
 double
 dynamic_cast
 else
 enum
 extern
 false
 float
 for
 friend
 goto
 if
 inline
 int
 long
 mutable
 namespace
 new
 not
 not_eq
 operator
 or
 or_eq
 private
 protected
 public
 register
 reinterpret_cast
 return
 short
 signed
 sizeof
 static
 static_cast
 struct
 switch
 template
 this
 throw
 true
 try
 typedef
 typeid
 union
 unsigned
 using
 virtual
 void
 volatile
 wchar_t
 while
 xor
 xor_eq
--

-- Ronald F. Guilmette, Sunnyvale, California -------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

>>>>> "Jim" == Jim Adcock <jimad@microsoft.com> writes:

Jim> I disagree with this decision, because with the bidi
Jim> autoconversion, I don't see where bool buys you much [other than
Jim> three new keyword conflicts].

- I hope vendors will offer an optional warning about auto-conversions
to and from bool.

- If people actually start using this type instead of inventing their
own, maintenance will become less confusing.  For example, SunOS 4.1.1
has 11 definitions of `TRUE' under /usr/include, three of them
different.

jimad@microsoft.com (Jim Adcock) writes:

>mitek@nic.cerf.net (Mitek Systems) writes:
>|....Meanwhile, the committee is adding keywords left and right.
>|
>|I don't want to reignite the dying embers of the 0 vs. NULL wars, but
>|I would like to point out that the "break old code" argument
>|seems to be pretty meaningless in light of the committee's actions.
>
>Not a meaningless argument.  In many cases 'fixing' the shortcomings
>of C or C++ means breaking existing code.  When such a possibility
>arises one valid argument is 'but doing so would break existing code!'
>The other valid argument is 'we have to break code in this case to
>fix the language and make forward progress.'  It remains to the committee
>then to decide *which* argument is more important.  In this case I
>guess they decided to quell the critics who complain that C/C++ doesn't
>even have a boolean type.

Having read the proposal, it sounds more like they just wanted to avoid
problems with different libraries using different user-defined boolean
types.

>I disagree with this decision, because with
>the bidi autoconversion, I don't see where bool buys you much [other
>than three new keyword conflicts].

If the three keywords are standardized, then in the long run there
will be *less* conflicts than if every library defines their own
different boolean type.

--
Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

In <comp.std.c++> hall_j@sat.mot.com (Joseph Hall) writes:

Note that these are also in C now.

>  and
>  and_eq
>  bitand
>  bitor
>  compl
>  not

You forgot not_eq.

>  or
>  or_eq
>  xor
>  xor_eq

Reference:

Amendment 1 to ISO/IEC 9899:1990 Programming Language C on: Integrity
Addendum, Committee Draft ISO/IEC Cd 9899:1990 PDAM 1, Document number
ISO/IEC JTC1/SC22 N1443.  Date of issue: September 1993.

In article <rfgCHqI8A.EGt@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
> What follows is the complete list of C++ keywords (as of the end of the
> recent X3J16/WG21 meeting in San Jose):
>
>    and
>     and_eq

>     bitand
>     bitor

>     compl

>     not
>     not_eq

>     or
>     or_eq

>     xor
>     xor_eq


Sorry if I missed this before, but are these keyboard-safe equivalents
of, respectively, "&&", "&=", "&", "|", "~", "!", "!=", "||", "|=",
"^", "^="?

If so, I would think it would be a little less confusing if they were
instead named "and", "bitand_self", "bitand", "bitor", "compl", "not",
"not_eq", "or", "bitor_self", "xor", "xor_self".  That is, there seems
to be an unnecessary ambiguity to "and*", "or*", and "*_eq".

I guess it is decided already, but I was just wondering.

Also, are there now bigraphs (not trigraphs) for other keyboard-unsafe
symbols?


thanks,
robt

--
Robert Mollitor            robert@visix.com
Visix Software Inc.     ...!uupsi!visix!robert

In article <KANZE.93Dec6171747@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze) writes:
>In article <2dsbvu$2j6@nic.lth.se> dag@control.lth.se (Dag Bruck)
|Seriously, I think that something is needed for the null pointer
|constant, too.  People just don't expect 'f( NULL )' to call 'f( int )'
|if there is an 'f( char* )' handy.
|--

However, even if a nil or null keyword or whatever is defined,
f(NULL) will continue to call f(int) unless one was able to hunt down
and kill all the places in all the header files that C and C++ programmers
have defined what they 'know' 'null', 'nil' or 'NULL' means.  Because
the preprocessor still gets first shot at screwing things up.
Further, you'd have to track down and kill all the C++ files where
C++ programmers have used 0 to mean nil because they didn't want
to run into problems with C programmers who define NULL to be what
they 'know' it to be.

Wanting a solution is not the same as having one.

In article <2dsbvu$2j6@nic.lth.se> dag@control.lth.se (Dag Bruck)
writes:

|> One of the great advantages of a built-in boolean type is that you get
|> overloading on booleans.  That argument does not apply to "nil".

One of the great advantages of a built-in nil literal is that you
don't get the unexpected overload which occurs when NULL is defined as
0.  That argument does not apply to bool:-).

Seriously, I think that something is needed for the null pointer
constant, too.  People just don't expect 'f( NULL )' to call 'f( int )'
if there is an 'f( char* )' handy.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

In article <CHJntE.1ow@ucc.su.OZ.AU>, maxtal@physics.su.OZ.AU (John Max
Skaller) wrote:

>  I'd be extremely surprised if bool, true, and false
> were not keywords. int is a keyword.  bool had better be.

I just got the minutes to the committee's San Jose meeting.
Dag Bruck and Andy Koenig proposed that bool, true, and false
be keywords.  The issue was raised that they need not be keywords.
Dag Bruck's answer (as per the minutes) justified why they may as
well be keywords.  I don't see a strong argument either way.
C++ has both keyword type names and typedef type names,
so "bool had better be" a keyword doesn't follow.

Anyway, the motion passed with no changes.  So contrary to what
I expected we have keywords.
--
Scott Turner
Liant Software Corp.
959 Concord St., Framingham, MA 01701  USA
(508)872-8700
pkt@lpi.liant.com

In article <pkt-061293114830@138.52.2.129>, pkt@lpi.liant.com (Scott Turner) writes:
|> I don't see a strong argument either way.
|> C++ has both keyword type names and typedef type names,
|> so "bool had better be" a keyword doesn't follow.
|>
|> Anyway, the motion passed with no changes.  So contrary to what
|> I expected we have keywords.

Thank goodness.

Aren't typedefs really just weak aliases?  That is, "typedef int
bool" would mean that "bool" had to be treated as "int".  By
having keywords, we open the possibility for stronger type
checking.

I dream of an optional compiler warning in some implementations
that will warn of any if(...), while(...), or such expression
that is not (prior to any bool promotion) naturally of type
bool.

--

    I won't rest till it's the best ...
    Software Production Engineer
    Paul Jackson (pj@sgi.com), x1373

In <comp.std.c++> pj@sam.wpd.sgi.com writes:
>In article <...>, pkt@lpi.liant.com (Scott Turner) writes:
>|> Anyway, the motion passed with no changes.  So contrary to what
>|> I expected we have keywords.
>
>Aren't typedefs really just weak aliases?  That is, "typedef int
>bool" would mean that "bool" had to be treated as "int".

That is quite correct; bool must be a built-in type to get the
benefits we aimed for.

However, it would most likely have been feasible to put bool in a
magic so-called namespace defined outside file scope, which would have
allowed redefinition of these words.

The concensus was that the three new reserved words will become
de-facto reserved by virtue of their commonality, even if it is
technically possible to redefine them.  If an application has defined
e.g. bool to act as a boolean datatype, the program will most likely
continue to run as before if you just remove your definition and use
the built-in type instead.

Programs that use something called "bool" as a number (i.e., with more
that two distinct values) will break, and deserve to break in my view.

Please forgive me if I'm so brief that it makes the posting hard to
read.


    -- Dag

In <comp.std.c++> pkt@lpi.liant.com (Scott Turner) writes:
>In article <2e0frk$cd2@fido.asd.sgi.com>, pj@sam.wpd.sgi.com (Paul Jackson)
>wrote:
>
>> I dream of an optional compiler warning in some implementations
>> that will warn of any if(...), while(...), or such expression
>> that is not (prior to any bool promotion) naturally of type
>> bool.
>
>I agree with you and Dag Bruck that to get any benefits, 'bool' must
>refer to a unique built-in type.

It may be worth spending time on something that did *not* get voted
into the standard working paper.  The original paper proposed that
conversions

 int  =>  bool
 T*   =>  bool

would be allowed, but declared as deprecated; this would be a strong
encouragement to issue a warning when an int or a pointer is
implicitly converted to a boolean (a narrowing conversion, if any!).
Note however that "if(i)" etc. would not cause a warning (an explicit
exception for compatibility reasons).

The committee voted aginst making the above casts deprecated, on the
grounds that constructs like

 char* p = ....;

 if (p && *p) ....; // Deprecation proposed

are common and also good style.  I personally think it isn't good
style, but it was not an issue worth fighting about.  I think we made
good progress anyway, and you must be prepared to compromise in a
standards committee (a major problem is that you must decide *quickly*
whether an issue is worth fighting for or not).

This was a minor digression, but I hope you found it interesting as an
illustration of how the standards committee works.

    -- Dag

In article <2dljos$40v@news.cerf.net> mitek@nic.cerf.net (Mitek Systems) writes:
|....Meanwhile, the committee is adding keywords left and right.
|
|I don't want to reignite the dying embers of the 0 vs. NULL wars, but
|I would like to point out that the "break old code" argument
|seems to be pretty meaningless in light of the committee's actions.
|
|

Not a meaningless argument.  In many cases 'fixing' the shortcomings
of C or C++ means breaking existing code.  When such a possibility
arises one valid argument is 'but doing so would break existing code!'
The other valid argument is 'we have to break code in this case to
fix the language and make forward progress.'  It remains to the committee
then to decide *which* argument is more important.  In this case I
guess they decided to quell the critics who complain that C/C++ doesn't
even have a boolean type.  I disagree with this decision, because with
the bidi autoconversion, I don't see where bool buys you much [other
than three new keyword conflicts].

We need to wait and see the details.  Perhaps this decision can meet your
needs too:

 FOO* pfoo = false;

;-)

In article <2e0frk$cd2@fido.asd.sgi.com>, pj@sam.wpd.sgi.com (Paul Jackson)
wrote:

> Aren't typedefs really just weak aliases?  That is, "typedef int
> bool" would mean that "bool" had to be treated as "int".  By
> having keywords, we open the possibility for stronger type
> checking.
>
> I dream of an optional compiler warning in some implementations
> that will warn of any if(...), while(...), or such expression
> that is not (prior to any bool promotion) naturally of type
> bool.

Yes, that would be cool IMO.  When I said that 'bool' could have been more
like a typedef name I was trying to say that the identifier 'bool'
might be subject to redefinition in a nested scope.  My idea was
_not_ that 'bool' would be an alias for some integral type that we have
inherited from C.

I agree with you and Dag Bruck that to get any benefits, 'bool' must
refer to a unique built-in type.
--
Scott Turner
Liant Software Corp.
959 Concord St., Framingham, MA 01701  USA
(508)872-8700
pkt@lpi.liant.com

Seems it was jimad@microsoft.com (Jim Adcock) who said:
>I don't see where bool buys you much [other than three new keyword conflicts].

Let's see ... is this a complete list?

(semi-new)
  catch
  try
  throw

(newer)
  dynamic_cast
  typeid
  namespace
  using
  and
  and_eq
  bitand
  bitor
  compl
  not
  or
  or_eq
  xor
  xor_eq

(brand new)
  bool
  true
  false

--
Joseph Nathan Hall |  Whales: smart food for smart people
Software Architect |
Gorca Systems Inc. |                 joseph@joebloe.maple-shade.nj.us (home)
(on assignment)    |         (602) 732-2549 (work)   Joseph_Hall@sat.mot.com

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

>Hidden at the end of a long article on the IOStream standard,
>maxtal@physics.su.OZ.AU (John Max Skaller) writes:

>>The committee just adopted a new data type -- bool -- as part of
>>the core language.

>Is this really true???
>Has the committee finally seen the light? ;-)
>Can someone please post more details about this?

>--
>Fergus Henderson                     fjh@munta.cs.mu.OZ.AU

If this true, then the committee has added yet another keyword.  Note that
I think this is a reasonable thing to do.  It just reminds me that when,
during the recent 0 vs. NULL wars, I proposed that "nil" might be a
reasonable replacement for both, language defenders popped up from all over
to say, "Noooo, that can't be done; it would break old code."
Meanwhile, the committee is adding keywords left and right.

I don't want to reignite the dying embers of the 0 vs. NULL wars, but
I would like to point out that the "break old code" argument
seems to be pretty meaningless in light of the committee's actions.


Shane
jsm@miteksys.com

In <comp.std.c++> mitek@nic.cerf.net (Mitek Systems) writes:
>If this true, then the committee has added yet another keyword.
>
>I don't want to reignite the dying embers of the 0 vs. NULL wars, but
>I would like to point out that the "break old code" argument
>seems to be pretty meaningless in light of the committee's actions.

One of the major problems with the current situation is that library
vendors already reserve various words for boolean types.  For example,
Solaris 2.2 defines "boolean", "B_FALSE", "B_TRUE" and "boolean_t" in
sys/types.h.  There are several other definitions of boolean types if
you look at common C and C++ libraries.

The committee has decided that it is better to have one boolean type
and three new reserved words, rather than "n" incompatible boolean
types and "m" reserved words.

The committee has proposed a standard string type.  Is that a step
backward because it breaks the string classes you and I have written?


     -- Dag

In article <2dljos$40v@news.cerf.net>, mitek@nic.cerf.net (Mitek Systems)
wrote:

> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
> >>The committee just adopted a new data type -- bool -- as part of
> >>the core language.

> If this true, then the committee has added yet another keyword.

Adding 'bool', 'true', and 'false' is indeed comparable to your
suggestion of adding 'nil', if they are done the same way.
But nobody said they were added as keywords, and it's reasonable to
expect that they were not.

dag@control.lth.se (Dag Bruck) writes:

>In <comp.std.c++> mitek@nic.cerf.net (Mitek Systems) writes:
>>If this true, then the committee has added yet another keyword.
>>
>>I don't want to reignite the dying embers of the 0 vs. NULL wars, but
>>I would like to point out that the "break old code" argument
>>seems to be pretty meaningless in light of the committee's actions.

>One of the major problems with the current situation is that library
>vendors already reserve various words for boolean types.  For example,
>Solaris 2.2 defines "boolean", "B_FALSE", "B_TRUE" and "boolean_t" in
>sys/types.h.  There are several other definitions of boolean types if
>you look at common C and C++ libraries.

>The committee has decided that it is better to have one boolean type
>and three new reserved words, rather than "n" incompatible boolean
>types and "m" reserved words.

>The committee has proposed a standard string type.  Is that a step
>backward because it breaks the string classes you and I have written?


>     -- Dag

My point was exactly this:  If it makes sense to add a keyword or
other language construct, then it makes sense to do so regardless
of whether it might break *some* code.  Just try compiling code
written for cfront 2.0 with a cfront 3.1 compiler, and you'll see
what I'm talking about.

Since there is no true C++ standard yet, there can be no code that
complies with it.  When (if?) a standard is completed, then the
committee should be very careful about backward-compatibility.
In the meantime, I'd rather see the committee do the right thing
for *future* code.  When the standard comes out we'll all have
to update our code anyway, so let's get it right the first time.

Off-the-cuff guess:  Adding bool, true, and false will break more
old code than adding nil.  I realize that it could be argued
that nil is of less value (and I don't mean nil<false==true :-).o


Shane "nil is better than nothing" McRoberts
jsm@miteksys.com

In article <pkt-031293110018@138.52.2.129> pkt@lpi.liant.com (Scott Turner) writes:
>In article <2dljos$40v@news.cerf.net>, mitek@nic.cerf.net (Mitek Systems)
>wrote:
>
>> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>> >>The committee just adopted a new data type -- bool -- as part of
>> >>the core language.
>
>> If this true, then the committee has added yet another keyword.
>
>Adding 'bool', 'true', and 'false' is indeed comparable to your
>suggestion of adding 'nil', if they are done the same way.
>But nobody said they were added as keywords, and it's reasonable to
>expect that they were not.

 I'd be extremely surprised if bool, true, and false
were not keywords. int is a keyword.  bool had better be.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In <comp.std.c++> mitek@nic.cerf.net (Mitek Systems) writes:
>
>Since there is no true C++ standard yet, there can be no code that
>complies with it.  When (if?) a standard is completed, then the
>committee should be very careful about backward-compatibility.

I think the committee has to care a lot about the code that has
already been written, even if there is no official C++ standard yet.

>Off-the-cuff guess:  Adding bool, true, and false will break more
>old code than adding nil.  I realize that it could be argued
>that nil is of less value (and I don't mean nil<false==true :-).o

One of the great advantages of a built-in boolean type is that you get
overloading on booleans.  That argument does not apply to "nil".

The argument that they share, is that you probably avoid the name
clash problem in the long run.

     -- Dag

In article <2dr31f$loi@news.cerf.net> mitek@nic.cerf.net (Mitek Systems) writes:
>
>Shane "nil is better than nothing" McRoberts

 Dear Shane "nil is better than nothing":

if you want "nil" in the language, write a paper on it, and I'll
submit it to the committee as an official document.

It will then be considered (in due course :-) by the extensions
group, who will either recommend to the full committee that
it be approved (possibly with modifications) or the extensions
group will decide it will not gain a clear majority in
full committee, or consensus on WG21, and reject the
proposal.

There is no point arguing about this on comp.std.c++.
There are those such as myself that completely agree with you
that adding a new keyword is not a major concern.
I'm not convinced that 'nil' is a good idea, but if I were,
I would have no qualms about using up an appropriate keyword
for it. Others might .. it all comes down to the voting procedures.

But .. without a written proposal, there is no chance that
an extension will make it into the language.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA