The FCD changed the text of 14.7.2/1 about the Status of dependency of a
function call to read like

"In an expression of the form:

postfix-expression ( expression-list[opt] )

where the postfix-expression is an unqualified-id , the unqualified-id
denotes a dependent name if and only if any of the expressions in the
expression-list is a type-dependent expression (14.7.2.2)."

This rule contradicts 14.7.2.2/3 which says

"An id-expression is type-dependent if it contains:
 - a conversion-function-id that specifies a dependent type,"

Since the time frame for FCD issue reports is over, i'm not sure where i
should send this issue to.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Aug 27, 2:28 pm, "Johannes Schaub (litb)" <schaub-johan...@web.de>
wrote:
> The FCD changed the text of 14.7.2/1 about the Status of dependency of a

Replace all 14.7.x with 14.6.x.

> function call to read like
>
> "In an expression of the form:
>
> postfix-expression ( expression-list[opt] )
>
> where the postfix-expression is an unqualified-id , the unqualified-id
> denotes a dependent name if and only if any of the expressions in the
> expression-list is a type-dependent expression (14.7.2.2)."
>
> This rule contradicts 14.7.2.2/3 which says
>
> "An id-expression is type-dependent if it contains:
>  - a conversion-function-id that specifies a dependent type,"

Why are conversion functions particularly significant? I think the
idea here is that such a function may be named by a typedef or
dependent typename.

The first thing in that list is

- an identifier associated by name lookup with one or more
declarations declared with a dependent type

So if an argument is declared with dependent type, the function
identifier is associated with a dependent type by name lookup, hence
dependent.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

David Krauss wrote:

> On Aug 27, 2:28 pm, "Johannes Schaub (litb)" <schaub-johan...@web.de>
> wrote:
>> The FCD changed the text of 14.7.2/1 about the Status of dependency of a
>
> Replace all 14.7.x with 14.6.x.
>

I'm sorry, I was using the document that hilights the changes (3090) instead
of the FCD itself (3092). Next time I take care :)

>> function call to read like
>>
>> "In an expression of the form:
>>
>> postfix-expression ( expression-list[opt] )
>>
>> where the postfix-expression is an unqualified-id , the unqualified-id
>> denotes a dependent name if and only if any of the expressions in the
>> expression-list is a type-dependent expression (14.7.2.2)."
>>
>> This rule contradicts 14.7.2.2/3 which says
>>
>> "An id-expression is type-dependent if it contains:
>>  - a conversion-function-id that specifies a dependent type,"
>
> Why are conversion functions particularly significant? I think the
> idea here is that such a function may be named by a typedef or
> dependent typename.
>

Yes, a conversion function can be named by a typedef. Two conversion
function names are equal if the type specified in them is the same (clause 3
- no lexical comparison, but semantical comparison is done).


> The first thing in that list is
>
> - an identifier associated by name lookup with one or more
> declarations declared with a dependent type
>

I skipped that, because the issue was with the thing i mentioned :) I
probably should have indicated that somehow.

> So if an argument is declared with dependent type, the function
> identifier is associated with a dependent type by name lookup, hence
> dependent.
>

But if I call "operator T()" there is no argument because the expression-
list is absent. So we don't have an expression that is type-dependent, and
this makes the name "operator T" non-dependent ("if and only if"). But
14.6.2.2/3 does make it dependent. This looks constradictory to me. Note
that C++03 did not say "unqualified-id" but just "identifier" here, which
did not include conversion function id's and thus is not affected by this
issue.

In any case, it should not make a difference for calls of kind "operator
T()", because a dependent function call can never end up calling a member
function of a dependent base class (DR #213). But there still is a
contradiction, at least the way I interpret that wording. So, is a ".
template" required in "operator T().foo<..>()" ? Yes, because it is
dependent, or no because it is not?

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Aug 28, 11:30 pm, "Johannes Schaub (litb)" <schaub-johan...@web.de>
wrote:

> Yes, a conversion function can be named by a typedef. Two conversion
> function names are equal if the type specified in them is the same (clause 3
> - no lexical comparison, but semantical comparison is done).

And, just for the sake of mentioning, any conversion-function-id is an
unqualified-id, even if the typename is "qualified" with "::". (5.1/1,
12.3.2/1)

> > So if an argument is declared with dependent type, the function
> > identifier is associated with a dependent type by name lookup, hence
> > dependent.
>
> But if I call "operator T()" there is no argument because the expression-
> list is absent. So we don't have an expression that is type-dependent, and
> this makes the name "operator T" non-dependent ("if and only if"). But
> 14.6.2.2/3 does make it dependent. This looks constradictory to me. Note
> that C++03 did not say "unqualified-id" but just "identifier" here, which
> did not include conversion function id's and thus is not affected by this
> issue.

Ah, of course :vP . I guess they got overzealous with the "and only
if."

> In any case, it should not make a difference for calls of kind "operator
> T()", because a dependent function call can never end up calling a member
> function of a dependent base class (DR #213). But there still is a
> contradiction, at least the way I interpret that wording. So, is a ".
> template" required in "operator T().foo<..>()" ? Yes, because it is
> dependent, or no because it is not?

Since it's impossible on the 1st pass to determine the return type of
a conversion function named by a conversion-function-id with a
dependent typename, it sounds like the parser would very much like a
".template foo<>()."


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]