Function overloading concern

[Walter Bright]

"Mike Capp" <mike.capp at gmail.com> wrote in message 
news:durud0$109b$1 at digitaldaemon.com...
> In article <dur2g6$29us$1 at digitaldaemon.com>, Walter Bright says...
>>I've seen that scheme. It strikes me as excessively complicated.
>>Furthermore, there are no implementations of it, so nobody knows if it is
>>implementable (see "export"), or if it is actually usable (see 
>>"namespace").
> In fairness, the proposal is by Daveed Vandevoorde of EDG, who AFAIK are 
> the
> only people on the planet who *have* implemented "export". I don't think 
> he's
> chucking this stuff out of the window of some ivory tower.

I have the greatest admiration and respect for Daveed. But nobody is smart 
enough to reliably predict how useful such a complex addition will be in 
practice, or what all the corner cases will be, or how difficult it is to 
implement on any compiler other than his own, etc., all based on a paper 
proposal.

Bottom line: the committee's track record on invention of complex new 
features is poor when they got standardized with no existing implementation 
experience (see namespace and export). The committee's record on 
standardizing functionality that *has* been extensively tried out is 
reasonably good (see STL).

> My main concern about the proposal as it currently stands is that I can't 
> see
> how build tools like "make" can possibly work with it. The model is no 
> longer
> "compile a bunch of separate objects and throw them at the linker". To 
> compile a
> source file you need to have compiled all source files it depends on, and 
> all
> source files *they* depend on, and so on. I'm increasing worried that the 
> whole
> module concept may not be workable in a language that doesn't allow 
> references
> to undeclared symbols at compile time.

I.e., it's a design for something that is complicated and quite unique among 
programming languages. It will *fundamentally* change the way C++ programs 
are built, probably in unanticipated ways. There's no implementation 
experience to see how it will work in a real project.

The risk is that if it gets standardized without being tried, and then 
people find out that it is either unworkable, unusable, or has little 
benefit in the real world, then it cannot be taken out again (like export).