"Russell Yanofsky" <russell.yanofsky@us.army.mil> writes:

> "William M. MikeMiller" wrote:
>> This issue is now under active discussion on the Standard
>> Committee's core working group email reflector, and it will be
>> discussed at next week's Committee meeting.
>
> Glad to hear it's being discussed. I don't know what an "email
> reflector" is,

It's just a mailing list.

> but I'd be interested in reading the discussion if it's publicly
> available somewhere.

Unfortunately, those lists are only accessible to non-committee
members rarely, and by special permission.

>> Personally, I don't see an inconsistency here.  The difference
>> between your examples is the difference between "...& const" and
>> "...const &".
>
> No. It's the difference between "& const" and "& const &." Why ignore
> the const qualifier in the first case and apply it in the second case
> when you can just be simple and consistent and either always ignore it
> or always apply it.
>
> The things you say about c++ doing similar type adjustments in other
> parts of the language are true. And I understand your more complicated
> way of looking at the const like it modifies the second & rather than
> the first. But there are good reasons for making those adjustments.
> What advantages does the extra complexity offer us in this case?

FWIW, at Mont Tremblant last week the core language working group
resolved that the outer cv-qualifier and reference should be dropped.
In other words, if T is int&, T const& is also int&.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Russell Yanofsky wrote:
> The proposed "reference collapsing" solution to CWG Defect 106 [1]
> treats cv-qualifiers on reference types differently than other parts of
> the language. Consider the following function declaration:
>
>   typedef int &int_ref;
>   void foo(int_ref const); // equivalent to void foo(int &);
>
> The current C++ standard in 8.3.2p1 requires that the const qualifier
> on the int_ref type be ignored. Now consider a similar declaration
> which would be allowed under DR106:
>
>   typedef int &int_ref;
>   void foo(int_ref const &); // equivalent to void foo(int const &);
>
> In this case, DR106 requires that the const qualifier be applied. So,
> in one case, the const qualifier is applied, in the other it isn't,
> even though the two declarations are identical except for a redundant &
> operator.

This issue is now under active discussion on the Standard
Committee's core working group email reflector, and it will be
discussed at next week's Committee meeting.

Personally, I don't see an inconsistency here.  The difference
between your examples is the difference between "...& const" and
"...const &".  Adding a top-level reference to a parameter type
prevents other kinds of type adjustments (e.g., dropping a
top-level const from a parameter type when creating the function
type, array-to-pointer and function-to-pointer decay), so it
seems reasonable (to me, at least) that adding a top-level
reference to a "const int_ref" would also prevent the discarding
of the const qualifier.

Furthermore, it seems reasonable (to me) that a person who
declares a "const T& t" should be able to rely on const semantics
for "t", that you should be able to distinguish overloaded
functions with "T&" and "const T&" parameters, etc., without
having to worry about whether T is a reference type or not.

There are different views represented on the Committee, so I'm
sure we'll have an interesting discussion next week.  It's
already been interesting on the core reflector.

> I don't see why it needs to be this way. It'd be better if DR-106 were
> either scaled back so cv-qualifiers on references were consistently
> ignored throughout the language, or broadened so they could be
> consistently applied.

Again, from my perspective, cv-qualifiers on references _are_
consistently ignored throughout the language; according to the
issue 106 resolution, "const int_ref&" is a reference to a
cv-qualified type, not a cv-qualified reference.

We will be discussing the other alternative you mentioned,
namely, not ignoring cv-qualification on top-level reference
types.  We have something of a parallel situation already in the
language with the way cv-qualified array types qualify the
element type as well, so something like that might be reasonable
for reference types, too.  However, that kind of change clearly
would break some code, although it's not clear how much, and no
one has done much analysis yet on how such a change might be
defined nor on its impact.

> I wonder if the author/authors of this
> proposal were aware of 8.3.2p1 and how it conflicts (conceptually) with
> the behavior they specify for reference collapsing.

Aware of 8.3.2p1, yes; viewing it as a conflict, no.  8.3.2p1
deals with cv-qualification of top-level references, which is not
what happens in the issue 106 resolution.

--
William M. (Mike) Miller | Edison Design Group, Inc.
wmm@world.std.com

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"William M. MikeMiller" wrote:
> This issue is now under active discussion on the Standard
> Committee's core working group email reflector, and it will be
> discussed at next week's Committee meeting.

Glad to hear it's being discussed. I don't know what an "email
reflector" is, but I'd be interested in reading the discussion if it's
publicly available somewhere.

> Personally, I don't see an inconsistency here.  The difference
> between your examples is the difference between "...& const" and
> "...const &".

No. It's the difference between "& const" and "& const &." Why ignore
the const qualifier in the first case and apply it in the second case
when you can just be simple and consistent and either always ignore it
or always apply it.

The things you say about c++ doing similar type adjustments in other
parts of the language are true. And I understand your more complicated
way of looking at the const like it modifies the second & rather than
the first. But there are good reasons for making those adjustments.
What advantages does the extra complexity offer us in this case?

- Russ

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

The proposed "reference collapsing" solution to CWG Defect 106 [1]
treats cv-qualifiers on reference types differently than other parts of
the language. Consider the following function declaration:

  typedef int &int_ref;
  void foo(int_ref const); // equivalent to void foo(int &);

The current C++ standard in 8.3.2p1 requires that the const qualifier
on the int_ref type be ignored. Now consider a similar declaration
which would be allowed under DR106:

  typedef int &int_ref;
  void foo(int_ref const &); // equivalent to void foo(int const &);

In this case, DR106 requires that the const qualifier be applied. So,
in one case, the const qualifier is applied, in the other it isn't,
even though the two declarations are identical except for a redundant &
operator.

I don't see why it needs to be this way. It'd be better if DR-106 were
either scaled back so cv-qualifiers on references were consistently
ignored throughout the language, or broadened so they could be
consistently applied.

Also, this inconsistency can make implementing DR-106 a PITA for
compiler writers, because you can longer interpret type expressions
"int_ref const &" straight from left to right. You used to be able know
what the "const" on "int_ref const" was supposed to do as soon as you
encountered it, whereas now you have to peek ahead for "&" operators to
know whether or not to apply it. At least that was my experience trying
to implement DR106 for GCC. I wonder if the author/authors of this
proposal were aware of 8.3.2p1 and how it conflicts (conceptually) with
the behavior they specify for reference collapsing.

- Russ

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#106

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

The proposed "reference collapsing" solution to CWG Defect 106 [1]
treats cv-qualifiers on reference types differently than other parts of
the language. Consider the following function declaration:

  typedef int &int_ref;
  void foo(int_ref const); // equivalent to void foo(int &);

The current C++ standard in 8.3.2p1 requires that the const qualifier
on the int_ref type be ignored. Now consider a similar declaration
which would be allowed under DR106:

  typedef int &int_ref;
  void foo(int_ref const &); // equivalent to void foo(int const &);

In this case, DR106 requires that the const qualifier be applied. So,
in one case, the const qualifier is applied, in the other it isn't,
even though the two declarations are identical except for a redundant &
operator.

I don't see why it needs to be this way. It'd be better if DR-106 were
either scaled back so cv-qualifiers on references were consistently
ignored throughout the language, or broadened so they could be
consistently applied.

Also, this inconsistency can make implementing DR-106 a PITA for
compiler writers, because you can longer interpret type expressions
"int_ref const &" straight from left to right. You used to be able know
what the "const" on "int_ref const" was supposed to do as soon as you
encountered it, whereas now you have to peek ahead for "&" operators to
know whether or not to apply it. At least that was my experience trying
to implement DR106 for GCC. I wonder if the author/authors of this
proposal were aware of 8.3.2p1 and how it conflicts (conceptually) with
the behavior they specify for reference collapsing.

- Russ

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#106

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]