In article <9bhv7a$9fmu7$1@ID-62495.news.dfncis.de>, Andrei Iltchenko says...

>Section: 13.3.1.1.2 - Call to object of class type [object.call.object]
>Submitter: Andrei Iltchenko (iltchenko@yahoo.com)
>
>According to 13.3.1.1.2 [object.call.object] paragraph 2, when the
>primary-expression E in the function call syntax evaluates to a class object
>of type "cv T", a surrogate call function corresponding to an appropriate
>conversion function declared in a direct or indirect base class B of T is
>included or not included in the set of candidate functions based on class B
>being accessible.

[ SNIP example ]

>The fact that the accessibility of a base class influences the overload
>resolution process contradicts the fundamental language rule (3.4
>[basic.lookup] paragraph 1, and 13.3 [over.match] paragraph 2) that access
>checks are applied only once name lookup and function overload resolution
>(if applicable) have succeeded.

I agree with the observation. 13.3/2 explicitly references section
13.3.1.1.2, so 13.3/4 should apply to 13.3.1.1.2 too.

>Suggested resolution:
>
>In 13.3.1.1.2 [object.call.object] paragraph 2 replace the last sentence
>
>"Similarly, surrogate call functions are added to the set of candidate
>functions for each conversion function declared in an accessible base class
>provided the function is not hidden within T by another intervening
>declaration."
>
>with
>
>"Similarly, surrogate call functions are added to the set of candidate
>functions for each conversion function declared in a base class of T
>provided the function is not hidden within T by another intervening
>declaration. If such a surrogate function is eventually selected as the best
>viable function and its corresponding conversion function is from an
>ambiguous (10.2) base class of T, the program is ill-formed."

I'm not sure if this wording solves the issue. The issue was about access,
not ambiguity? Shouldn't the wording refer to 13.3 and 3.4, which you
mentioned earlier? I had expected something like "

Similarly, surrogate call functions are added to the set of candidate
functions for each conversion function declared in a base class of T
provided the function is not hidden within T by another intervening
declaration. If such a surrogate function is eventually selected as the
best viable function and it is not accessible (11.2) in the function call scope,
the program is ill-formed."

I.e. Shouldn't the wording refer to 11.2 instead of to 10.2 ?
>Regards,
>Andrei Iltchenko.

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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.research.att.com/~austern/csc/faq.html                ]

 [Moderator's note: this defect report has been
 forwarded to the C++ committee. -moderator.]

Section: 13.3.1.1.2 - Call to object of class type [object.call.object]
Submitter: Andrei Iltchenko (iltchenko@yahoo.com)

According to 13.3.1.1.2 [object.call.object] paragraph 2, when the
primary-expression E in the function call syntax evaluates to a class object
of type "cv T", a surrogate call function corresponding to an appropriate
conversion function declared in a direct or indirect base class B of T is
included or not included in the set of candidate functions based on class B
being accessible.

For instance in the following code sample, as per the paragraph in question,
the expression "c(3)" shall call f2, instead of the construct being
ill-formed due to the conversion function "A::operator fp1" being
inaccessible and its corresponding surrogate call function providing a
better match than the surrogate call function corresponding to "C::operator
fp2":

void  f1(int)  {   }
void  f2(float)  {   }
typedef void  (* fp1)(int);
typedef void  (* fp2)(float);

struct  A  {
   operator fp1()
   {   return  f1;   }
};

struct  B :  private A  {   };

struct  C :  B  {
   operator  fp2()
   {   return  f2;   }
};

int  main()
{
   C   c;
   c(3);  // f2 is called, instead of the construct being ill-formed.
   return  0;
}

The fact that the accessibility of a base class influences the overload
resolution process contradicts the fundamental language rule (3.4
[basic.lookup] paragraph 1, and 13.3 [over.match] paragraph 2) that access
checks are applied only once name lookup and function overload resolution
(if applicable) have succeeded.

Suggested resolution:

In 13.3.1.1.2 [object.call.object] paragraph 2 replace the last sentence

"Similarly, surrogate call functions are added to the set of candidate
functions for each conversion function declared in an accessible base class
provided the function is not hidden within T by another intervening
declaration."

with

"Similarly, surrogate call functions are added to the set of candidate
functions for each conversion function declared in a base class of T
provided the function is not hidden within T by another intervening
declaration. If such a surrogate function is eventually selected as the best
viable function and its corresponding conversion function is from an
ambiguous (10.2) base class of T, the program is ill-formed."


Regards,

Andrei Iltchenko.
---
[ 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.research.att.com/~austern/csc/faq.html                ]