Re: [boost] 'function' idea

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-11-20 14:43:58

On Wednesday 20 November 2002 01:38 pm, Paul Mensonides wrote:
> > I don't think it's quite so clear-cut, because we have to define what you
>
> mean
>
> > by "nonsense", and I'm not sure you'll find agreement. The committee
> > chose one view of nonsense: trying to form any type that isn't a C++ type
> > (e.g., typename int::foo) is nonsense, so deduction fails.
>
> This isn't what that section means however.  It is only a list a few cases
> of "trying to form any type that isn't a C++ type."

... but I've stated what was the intent of the committee (according to my 
recollection from talking with Daveed); that is, to fail when one tries to 
form a type that isn't a C++ type. Do you have any specific cases they have 
missed? If so, then there is a defect and we should report it. Note that 
sizeof()-based cases (that rely on semantic checks) don't apply, because they 
aren't based on forming new types and should cause a real error (not template 
argument deduction failure).

> I'm talking about the strict interpretation of the standard (14.8.3)--not
> what current compilers do.  Type deduction happens *before* overload
> resolution--i.e. in the process or building a candidate set.  The template
> function just has to be visible.  So, in order for the function to "never
> make it into the overload set," it has to fail type deduction (i.e. not
> pass and _not_ error).

There's a _huge_ miscommunication here. I'm talking about your proposed 
resolution, and assuming that we adopt the rule "template argument deduction 
fails if the result is a semantically invalid declaration". One can then 
write a function template whose declaration will _always_ be ill-formed, so 
it will never succeed at template argument deduction. How will the user get 
an error when trying to call this function? (Answer: use a C++98 compiler, 
which will emit an error on any attempt to instantiate the function template 
declaration).

The issue I have is that your resolution may make it easier to write code that 
"compiles", but only because the definition is never actually instantiated. 
And when it's easier to write bad code that the compiler won't catch, it's 
harder to learn the language. 

> > Also note that this change is a huge problem for backward compatibility.
>
> That
>
> > badly broken function template from above is silently useless on C++0x,
>
> but
>
> > step back to C++98/C++02 and its going to fail.
>
> This isn't a case of a "badly broken function template," nor is a case of
> it being "silently useless."  It can be a perfectly worthwhile function
> template. 

Do you have a concrete example? This would help us greatly.
 
> This change would do several things,
> 1) cleanup that section of the standard,

"Cleanup" is not a good word to use when we're talking about a change in 
semantics. Cleanup can refer to adding missing cases, introducing rationale, 
or tighening up the wording in accordance with the intent of the section.

> 2) unify the rules with
> declaration instantiation ala member functions,

I'm not sure what you mean by this.

> 3) give us a huge set of tools to work with for generic programming, and

If we're going to be changing semantics, why not introduce new tools that 
support our goals better? 

> 4) close a potentially
> serious hole in the C++ overload mechanism.  What this change *wouldn't* do
> is alter the results on overload resolution in any way, nor would it allow
> more functions into the candidate set.

I don't understand this at all. Where is the hole in the C++ overload 
mechanism? We're only talking about template argument deduction, which is not 
overloading.

> > ... but don't forget that once we get more language primitives, that will
> > enable new tricks as well.
>
> Yes.  My point is that whatever gets added to 0x is not going to solve all
> of our needs.  We should never throw away worthwhile tools--even if some of
> them make us bend over backward to accomplish something (i.e. the sizeof
> hack).
>
> Paul Mensonides

We don't have this tool now, so there is nothing to throw away. 

        Doug

[This is getting way off-topic for Boost. We should take this off-line or over 
to clc++m)