Function overloading concern

[Mike Capp]

In article <dur2g6$29us$1 at digitaldaemon.com>, Walter Bright says...
>
>"Sean Kelly" <sean at f4.ca> wrote in message 
>news:duqh7n$1l6c$1 at digitaldaemon.com...
>> There's been a recent push to adopt a module import scheme for C++, but I 
>> think the huge mass of legacy code like the above will make the scheme 
>> very difficult to use.

The proposal is actually pretty good about backward compatibility. The
transition would be messy, yes, but transitions always are.

>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.

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.

cheers
Mike