Title
Accessibility and ambiguity
Status
tc1
Section
7.11 [conv.ptr]
Submitter
Nathan Sidwell

Created on 1999-07-31.00:00:00 last changed 208 months ago

Messages

Date: 1999-10-15.00:00:00

Proposed resolution (10/00):

  • 8.2.7 [expr.dynamic.cast] paragraph 8, bullet 2: change "unambiguous public base class" to "unambiguous and public base class"
  • 13.3 [class.virtual] paragraph 5: change "the class in the return type... is an unambiguous direct or indirect base class... and is accessible in D" to "the class in the return type... is an unambiguous and accessible direct or indirect base class..."

Date: 2003-04-25.00:00:00

The Standard uses confusing terminology when referring to accessibility in connection with ambiguity. For instance:

7.11 [conv.ptr] paragraph 3:

If B is an inaccessible or ambiguous base ...
8.2.7 [expr.dynamic.cast] paragraph 8:
... has an unambiguous public base ...
13.3 [class.virtual] paragraph 5:
... is an unambiguous direct or indirect base ... and is accessible ...
18.3 [except.handle] paragraph 3:
not involving conversions to pointers to private or protected or ambiguous classes

The phrase "unambiguous public base" is unfortunate as it could mean either "an unambiguous base not considering accessibility, which is public" or "an unambiguous base considering only the publicly accessible bases." I believe the former interpretation correct, as accessibility is applied after visibility (14 [class.access] paragraph 4) and ambiguity is described in terms of visibility (13.2 [class.member.lookup] paragraph 2).

Suggested Resolution: Use the phrases "public and unambiguous," "accessible and unambiguous," "non-public or ambiguous," or "inaccessible or ambiguous" as appropriate.

History
Date User Action Args
2003-04-25 00:00:00adminsetstatus: dr -> tc1
2000-11-18 00:00:00adminsetstatus: ready -> dr
2000-05-21 00:00:00adminsetstatus: review -> ready
2000-02-23 00:00:00adminsetmessages: + msg216
2000-02-23 00:00:00adminsetstatus: open -> review
1999-07-31 00:00:00admincreate