Am Dienstag, den 11.08.2020, 14:10 -0700 schrieb Richard Smith:
> On Tue, Aug 11, 2020 at 2:05 PM Uecker, Martin via Liaison <
> liaison_at_[hidden]> wrote:
>
> > Am Dienstag, den 11.08.2020, 17:01 -0400 schrieb Aaron Ballman:
> > > On Tue, Aug 11, 2020 at 4:45 PM Uecker, Martin
> > > <Martin.Uecker_at_[hidden]> wrote:
> > > >
> > > > Am Dienstag, den 11.08.2020, 16:41 -0400 schrieb Aaron Ballman:
> > > > > On Tue, Aug 11, 2020 at 4:38 PM Uecker, Martin via Liaison
> > > > > <liaison_at_lists.isocpp.org> wrote:
> > > > > >
> > > > > >
> > > > > > BTW: Is
> > > > > >
> > > > > > if (x)
> > > > > > int y;
> > > > > >
> > > > > > intentionally allowed in C++? Is there a sensible use
> > > > > > case?
> > > > >
> > > > > Yes, that's well-formed C++ code. A possible use case would be for an
> > > > > RAII object which performs work in its constructor or destructor (so
> > > > > the declaration itself causes code to be executed).
> > > >
> > > > I understand this. I was thinking more about a
> > > > high-level example where it would make sense to use
> > > > it in this way.
> > > >
> > > > A file which is opened and immediately close again
> > > > also does not make too much sense.
> > > >
> > > > But maybe there are better examples?
> > >
> > > My line of thinking may be contrived, but because constructors can
> > > accept arguments to them (including references or pointers to other
> > > objects), the RAII object could be performing some modification. e.g.,
> > >
> > > if (enable_special_magic)
> > > RAIIObject Special(Magic);
> > >
> > > where the constructor for RAIIObject takes an argument by reference
> > > and does something special to it (calls a function on it, modifies a
> > > value somewhere, etc). However, I wouldn't say this is a construct
> > > I've run across myself in the wild. As an example, perhaps the RAII
> > > object is logging to a file in the constructor (and perhaps flushing
> > > the file in the destructor).
> > >
> > > ~Aaron
> >
> > Thanks Aaron!
> >
> > I can see that it could potentially be used in some cases,
> > but it seems this was not added to the C++ language on purpose.

(And you can create an object and run the constructor without
declaration, so naming a variable here really makes no sense.)

> I think it depends on what you mean by "on purpose". The example here seems
> to suggest that it was fully intentional:
> http://eel.is/c++draft/stmt.select#2 .

Yes, but to me it seems more that paragraph 2 needed to be added
to fix scoping for this particular corner case of the language
and this is probably the sole reason the example is given.

> However, it seems likely that it's
> allowed for consistency (declarations are statements, 'if' allows any
> statement, therefore 'if' allows a declaration) rather than to enable a
> specific anticipated usage.

This makes sense. Someone made the decision that declarations
are statements. I assume the purpose was to allow labels to be
placed in front of declarations.

But this left open two corner cases:

- The 'if (1) int i;' example, because declarations were now
also allowed where only statements make sense.

- Placement of labels at the end of compound statements is
still not allowed. (which requires teaching people to add
pointless null statements)


In contrast, the new rule in C has neither problem and
is more logical: Labels are about control flow and make
sense everywhere where statements make sense.

(In contrast, declarations are about introducing names
and should interact well with scoping rules, so really
should follow different rules.)

Best,
Martin