It seems to me, based on my reading of the FDIS, that there's been a
small oversight and that the following example is technically invalid:

struct base { };
struct derived : ::base { };

Given:

base-specifier:
   attribute-specifier-seq[opt] base-type-specifier
   ...

class-or-decltype:
   nested-name-specifier[opt] class-name
   decltype-specifier

base-type-specifier:
   class-or-decltype

nested-name-specifier:
   '::'[opt] type-name '::'
   '::'[opt] namespace-name '::'
   decltype-specifier '::'
   nested-name-specifier identifier '::'
   nested-name-specifier 'template'[opt] simple-template-id '::'

There seems to be no way that a base-type-specifier can be simply
"::base". One way to address this would be to add a single nested-name-
specifier rule that was simply '::' which seems like what would be the
desired behavior (though perhaps makes the grammar rule name (nested-
name-specifier) a little erroneous since it now represents unnested
names too). It looks like most uses of nested-name-specifier might
suffer from this problem (though some cases explicitly account for it
in the standard text but possibly not in the grammar rules - 3.4.3p1
seems to have some description of this) or at least not be overly
harmed by it (one case that might be questionable is qualifying the
names of definitions originally declared inside namespaces - whether
it makes sense to define a globally declared foo from within a
namespace by using "void ::foo() { }" is questionable, I suppose)

I've checked through the current defect report lists&  nothing seemed
to stand out as representing this issue. I hope the description/
details are useful/correct/accurate.

- David


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Oct 26, 10:20 am, David Blaikie<dblai...@gmail.com>  wrote:
>  It seems to me, based on my reading of the FDIS, that there's been a
>  small oversight and that the following example is technically invalid:
>
>  struct base { };
>  struct derived : ::base { };
>
>  Given:
>
>  base-specifier:
>      attribute-specifier-seq[opt] base-type-specifier
>      ...
>
>  class-or-decltype:
>      nested-name-specifier[opt] class-name
>      decltype-specifier

As of N3242 this was adjusted to
   ::[opt] nested-name-specifier[opt] class-name

>  I've checked through the current defect report lists&    nothing seemed
>  to stand out as representing this issue. I hope the description/
>  details are useful/correct/accurate.

Indeed, there doesn't seem to be a DR covering this! I wonder if
there's a paper trail for this correction. I don't have the FDIS on
hand so I haven't verified that it was reverted.


--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Am 01.11.2011 19:15, schrieb David Krauss:
> On Oct 26, 10:20 am, David Blaikie<dblai...@gmail.com>   wrote:
>>   It seems to me, based on my reading of the FDIS, that there's been a
>>   small oversight and that the following example is technically invalid:
>>
>>   struct base { };
>>   struct derived : ::base { };
>>
>>   Given:
>>
>>   base-specifier:
>>       attribute-specifier-seq[opt] base-type-specifier
>>       ...
>>
>>   class-or-decltype:
>>       nested-name-specifier[opt] class-name
>>       decltype-specifier
>
> As of N3242 this was adjusted to
>     ::[opt] nested-name-specifier[opt] class-name

... but then came

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3259.htm

which tried to solve a similar problem (CWG 355) but seemingly failed to
do that properly. "The intention was good, but..."

>>   I've checked through the current defect report lists&     nothing seemed
>>   to stand out as representing this issue. I hope the description/
>>   details are useful/correct/accurate.
>
> Indeed, there doesn't seem to be a DR covering this! I wonder if
> there's a paper trail for this correction. I don't have the FDIS on
> hand so I haven't verified that it was reverted.

I should have responded to the OPs message that I forwarded the problem
description to the core language group (Sometimes I forget to reply).

Greetings from Bremen,

Daniel Kr   gler



--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]