"Sergey P. Derevyago" <non-existent@iobox.com> wrote in message news:<3F5204EE.9FCA9390@iobox.com>...
> Bob Bell wrote:
> > Of course, the answer is I can't know that. Nothing about the
> > declaration of f<T>() tells me that T::g() is the discriminating
> > member. The only way I can tell is if I can look at the _definition_
> > of f<T>(), which I may not be able to see (e.g., if the f<T>() is an
> > exported template).
>         You can laugh but documentation is much handier in addressing these kinds of
> issues :) And moreover you _must_ be able to see the documentation.

I wouldn't laugh, because I agree that documentation is important.
However, in the real world documentation is often inaccurate or
missing. The fact that overload on nothrow implies more reliance on
documentation is a strike against it, I'm afraid.

> > Also, this situation is quite different from today's use of templates.
>         Yes, and today's situation w.r.t. templates is nightmare :(

Overload on nothrow seems to make it more complex, not less.

> > With today's templates, if I try to call f<T>(), and internally f<T>()
> > calls T::g(), and there is no T::g(), I get a compiler error. Either
> > it compiles, or it doesn't, and if it compiles, the function that gets
> > called is determined wholly by the interface of the available
> > f<T>()'s.
>         The sad truth is that today's f<>() is always marked as canthrow: "You can
> have any exception specification as long as it's canthrow."

The happy truth is that today overloading is based entirely on the
interfaces of functions. Overload on nothrow would change that, and
create dependencies between implementations, which would be a step
backwards.

Up till now you've ignored what I consider the most important
questions. We can haggle about syntax and semantics ad nauseum, but
some day you'll have to give answers to these questions:

Why do we need this feature?

What real-world problem does it solve?

How often does this problem come up in real-world code?

What are the workarounds we are forced to use if we want the effect of
this feature today, if it's even possible?

What disadvantages do the workarounds have?

How does this feature interact with other language features
(overloading, specialization, name lookup, etc.)?

What are the disadvantages of this feature, and how do they compare
with the disadvantages of the workarounds?

As far as I know, any feature considered for standardization must have
pretty compelling answers to these and similar questions.

Bob



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]