Re: [boost] 'function' idea

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-11-19 14:11:15

On Wednesday 13 November 2002 04:50 am, Aleksey Gurtovoy wrote:
> Paul Mensonides wrote:
> > This is unacceptable.  What really needs to happen, is the
> > rules regarding declaration instantiation of template class
> > members need to be merged with type-deduction failure.  I.e.
> > If the result is semantically invalid, the function is removed
> > from the overload set (excepting only a few things such as
> > applying 'const' to a type that is already 'const' and possibly
> > the reference to reference issue).  Period.  This is the only
> > safe way to go, and conveniently, would allow for all sorts of
> > traits tests that currently rely on compiler extensions.
>
> Agreed, that's basically what is wanted. The challenge is to execute
> something along the lines of the Doug's plan successfully ;).
>
> Aleksey

Oops, I dropped the ball on this one. 

Last week I got the opportunity to ask Daveed Vandevoorde about this. 
Specifically, I mentioned the gap in the type deduction failure rules 
introduced by sizeof and asked if (a) the committee knew about this when they 
drafted the clause and (b) what type of resolution we could expect if we 
asked the committee to clarify this clause with respect to sizeof.

Daveed said that the intent of the clause is to ensure that the compiler is 
never forced to create a type that is not well-formed. The the committee did 
understand the problem sizeof caused when they drafted this clause, and that 
they went through various forms of specification: listing all cases that 
could succeed, creating a blanket statement that says that deduction fails if 
there is any failure, or listing all cases that could fail. The impression I 
got was that for any case that isn't well-formed and doesn't fall into one of 
the categories for type-deduction failure, the program is ill-formed and the 
compiler should emit a diagnostic. (Aside: we should file a bug report with 
EDG with Paul's example, because it falls into this case and should emit an 
error instead of silently choosing the "wrong" one). We might still want to 
submit a DR to get this clarified for sure.

What's this mean for us? Well, I think it kills the idea that a resolution to 
a DR will give us the ability to check the compilability of any expression. 
This brings me to a comment Daveed made during his talk (paraphrased): when 
creating extensions for C++, don't forget what you actually want. We're 
saying that we'd like to fix the type-deduction failure rules to act in a 
certain way that makes our expression-checking hack work. We can't do this in 
the old C++ (and no DR is going to change that), so we should step back and 
ask "what exactly do we want to be able to do?"

I _think_ we want to be able to ask "what happens when we try to compile this 
expression?". Then I think the result should be one of:
  - ambiguous (the expression contains at least one ambiguity)
  - access control violation (the expression will compile, but there is an 
access violation that would cause a diagnostic)
  - ill-formed (the expression is ill-formed, but not because of an ambiguity 
or an access control violation)
  - well-formed (the expression will compile. this does not guarantee that the 
definitions of functions called in the expression can be instantiated, but 
only guarantees that the declarations can be instantiated)

        Doug