In article <smeyersDMBEsy.5M8@netcom.com> smeyers@netcom.com (Scott
Meyers) writes:

> A few months ago there was a discussion of whether the language should be
> extended so that const and non-const objects would have different
> constructors, the idea being that initialization for a const object might
> be different from initialization for a non-const object.  My understanding
> is the committee has rejected that idea.  Could someone please post a
> summary of the problems with the idea or point me to a place where I can
> find them?

It is too late in the standards process for any significant changes.
The extensions working group was disbanded several meetings ago
and the committee no longer has any mechanism for considering extensions.
--
    --Andrew Koenig
      ark@research.att.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]

smeyers@netcom.com (Scott Meyers) writes:

>A few months ago there was a discussion of whether the language should be
>extended so that const and non-const objects would have different
>constructors, the idea being that initialization for a const object might
>be different from initialization for a non-const object.  My understanding
>is the committee has rejected that idea.  Could someone please post a
>summary of the problems with the idea or point me to a place where I can
>find them?

One immediate problem is that to do it right would break backwards
compatibility, because you should not be able to invoke a non-const
constructor for a const object, just as you can't invoke a non-const
member function for a const object.  Code such as

 struct X { int a; X(); };
 const X x;

would have to be declared illegal, to be replaced with

 struct X { int a; X() const; };
 const X x;       ^^^^^

Breaking backwards compatibility like this would be a real problem.

There are other problems (e.g. initialization of arrays may become
very tricky) but I think the above problem would be sufficient to kill
the proposal.

--
Fergus Henderson              WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au               PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]