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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
