Valentin Bonnard  <Bonnard.V@wanadoo.fr> wrote:
>Nathan Myers writes:
>
>>  analogy to auto objects (irrelevant to the question)
>
>You said it was, others didn't agreed (at least me)

It was demonstrated, several times.  Others have agreed that you
cannot decide logically which alternative is better.  The analogy
to auto objects is an attempt to effect a choice based on the
internal logic of the language, independent of consequences.

You are (and always have been) welcome to prefer the status quo.
It is in your interest to have a logically-sound understanding
of your preference.

>>  template can't delete T (demonstrated otherwise)
>
>Still, the following doesn't compile:
>
>  template <typename T>
>  void foo () { delete new T; }
>  ... { foo<const int> (); }

Obviously.

This has already been dealt with many, many times, both recently and
in previous exchanges.  I doubt that you really need to see the
treatment again.

>>  want containers of const T (still illegal)
>
>I think that's mis-stating other's opinions.
>std::container<const T> is illegal for container=vector...
>
>Nothing prevents me from writing some Container class
>so that Container<const T> would be legal.
>
>(The STL didn't invent the notion of containers (in general).)

In any case nonstandard containers of const T were never precluded.
(See previous.)

>>  language lacks non-const no-delete feature (irrelevant)
>
>which mean that what you would prefer (ruling out delete const):
>- may belong elsewhere
>- is not so useful w/o the non-const no-delete feature
>
>People have argued that lifetime/constness were orthogonal.
>You have completely dismissed this argument (to use one of
>yours debating tactic).

Lifetime and changeability could be thought of orthogonally, if you
like.  To announce that lifetime/constness are orthogonal simply begs
the question.  Whether they should be treated othogonally is at issue.
You can't support an argument by announcing the conclusion.

How you choose to think of lifetime and changeability has no bearing
on the validity of the arguments that affected the vote, nor of the
engineering consequences of the change.  The language is filled with
constructs that combine two or more concepts, and we don't routinely
eliminate features on that basis.  (Try to count the concepts that may
be teased out of "int".)

We can equally well consider the issue in terms of four features:

  prevent calling non-const members
  prevent deletion of pointer-to-const
  allow deletion via cast of pointer-to-const
  prevent deletion of pointer-to-non-const

Presenting them this way sidesteps the syntactic issues.

We had the first three, and the actual vote (as it happened) was on
eliminating the second, and rendering the third irrelevant.  The
fourth was not mentioned, or ever (to my knowledge) even proposed.

To claim that the lack of that fourth feature makes the feature we had
"not so useful", though, is patently silly.  The feature we had was
_precisely_ as useful as it was.  An additional feature would also
be useful.

We lack "long long".  Does that make unsigned long "not so useful"?
We lack garbage collection.  Does that make new/delete "not so useful"?
I don't have a boat.  Does that make my car "not so useful"?

You demonstrate my point too forcefully.

>You said that Andrew's argument about the hypothetical no-delete
>qualifier just distracts the reader (as if Andrew intended to
>distract the reader from the current issue); but the same could
>be said about your mention of the delete pointer_to_incomplete_type,
>which has no relation what-so-ever with the the delete
>pointer_to_complete_const_type issue.

Deletion of incomplete types was another example of an unsound decision
process connected with dynamic object lifetime, and thus directly
connected with the stated topic.  It was not introduced in support of
any argument about the merits of deleting const pointers, and could
thus be ignored in discussion of that.

Andrew's mention of "no-delete" was an attempt to support an argument
in favor of having broken const.  That it failed to provide any such
support is very interesting in the context of the stated topic.

>You are wondering why people don't understand that delete const
>is bad.

I am not wondering any such thing.  As has been repeated (too?) many
times, the discussion is of why the invalid arguments that led to the
change were (and still are, in some quarters!) considered persuasive.

While _I_ think that "delete const" is bad, others have a different
opinion.  Thus far the arguments advanced in support of that opinion
have been very _interestingly_ flawed.

You did not mention the "Unix file permissions" argument.  Maybe that
is one which you agree was, and is, logically unsound?

You did not say you disagreed with the remarks about deletion of
incomplete types.  Would you prefer that your compilers not warn you
about such deletions?

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[ This article is more about the tone and debating techniques
  than about the issue in itself, even if it contains some
  comments about the issue in itself. ]

Nathan Myers writes:

> Again, it doesn't matter whether breaking const was right or wrong:
> the standard is what it is.  It does matter that "what it is" resulted
> from nonsensical arguments, because we should be equipped to recognize
> when a design issue arises which derails intelligent individuals'
> reasoning skills this way.

Valentin Bonnard could write:

: Again, it doesn't matter whether keeping delete from deleting pointers
: to const would have been right or wrong: your opinion is what it is.
: It does matter that "your opinion" resulted from nonsensical
arguments,
: because you should be equipped to recognize when a design issue arises
: which derails your reasoning skills this way -- the reasoning skills
: of someone really intelligent.

Nathan Myers writes:

>  analogy to auto objects (irrelevant to the question)

You said it was, others didn't agreed (at least me)

>  template can't delete T (demonstrated otherwise)

Still, the following doesn't compile:

  template <typename T>
  void foo () { delete new T; }

  foo<const int> ();

>  want containers of const T (still illegal)

I think that's mis-stating other's opinions.
std::container<const T> is illegal for container=vector...

Nothing prevents me from writing some Container class
so that Container<const T> would be legal.

(The STL didn't invented the notion of containers (in general).)

>  language lacks non-const no-delete feature (irrelevant)

which mean that what you would prefer (rulign out delete const):
- may belong elsewhere
- is not so useful w/o the non-const no-delete feature

People have argued that lifetime/constness were orthogonal.
You have completely dismissed this argument (to use one of
yours debating tactic).

You said that Andrew' argument about the hypothetical nodelete
qualifier just distracts the reader (as if Andrew intended to
distract the reader from the current issue); but the same could
be said about your mention of the delete pointer_to_incomplete_type,
which has no relation what-so-ever with the the
delete pointer_to_complete_const_type issue.

You are wondering why people don't understand that delete const
is bad. Well, I see it as a Good Thing, but if I did considered
it as a Bad Thing, I would certainly think that, the way you
``explain'' (your debating technics) maybe one of the reasons
people reject your point of view.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]