🚀 go-pugleaf

In article <48d6cu$8pv@engnews1.eng.sun.com>,
clamage@Eng.Sun.COM (Steve Clamage) writes:
[..]
|> Early in the C++ standardization process we had a nice proposal to
|> change built-in arrays in C++ to behave "properly". The size of the
|> array would be part of the type in function parameters, for example.
|> A lot of people (including me) liked the proposal on language-design
|> grounds, but the consensus was (including me) that it would seriously
|> break C compatibility, and so it was not adopted. Some breaks are
|> tolerated, but this one was considered too fundamental.

"Behaving properly" would be a severe change in the semantics of
array-params.  So IMO this decission is ok.

- The first step toward "behaving properly" would be DEPRECATION:
  a feature that might be removed in a next version of C++.
- The second step could be "remove array-params".
- And then, when there is no C++ code left with array-params
  one could do the third step:
  Reintroduction of array-params but now "behaving properly".

IMHO  deprecation is by itself an advantage  (without a future
second+third step) as it makes the problem of non-properly
behavior obvious to the programmer.
By not using array-params any more, new code will become less
errorprone and more honest, while old code will still compile
(with a 'diagnostic message').


Ulf Schuenemann

--------------------------------------------------------------------
 ,_.   Ulf Schuenemann
#,  \  Fakultaet fuer Informatik, Technische Universitaet Muenchen, Germany.
 |   > email: schuenem@informatik.tu-muenchen.de
 v=-<  WWW:   http://hphalle2.informatik.tu-muenchen.de/~schuenem/
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]