Re: C++ Frequently Questioned Answers
David Abrahams wrote:
on Wed Nov 07 2007, Walter Bright <walter-AT-digitalmars-nospamm.com> wrote:
David Abrahams wrote:
on Tue Nov 06 2007, Walter Bright <walter-AT-digitalmars-nospamm.com> wrote:
D somehow magically resolves all the ambiguities in just the way
the programmer wants, every time?
That's essentially what overload sets do.
Be serious now, and be honest. When function signatures don't have to
match argument types exactly there's no answer to overload resolution
that magically produces just the answer you want, *every* time. You
have to pay attention to changes in all the modules that can
participate in an overload set (in any language).
The key is that the cases in C++ that would give you silent semantic
changes give you compile time errors in D.
I'm sorry, but in a system where overload matches form a partial
ordering, that's just not possible in all cases. If you give modules
A and B permission to participate in an overload set for foo() just
for the purposes of not having to use qualification, it's always
possible that the "best match" will unintentionally switch from module
A to module B.
That's why such cases give a compile time error in D. A match that is a
better match for A.foo than B.foo issues an error. Only if there is a
match for A.foo and NO MATCH AT ALL for B.foo does it compile at all.
This makes it impossible for a change in B to silently 'hijack' a
reference to A.foo over to B.foo.
It is not an issue of which is a better match, it's that overload
sets cannot intersect. It's a bit of a hard thing to explain without
sitting down with pencil and paper.
Once two modules are allowed into an overload set, you can have all
the same problems. What I've seen of your system is great, really:
problems are certainly are going to be less likely than in C++. Just
don't oversell what you've got.
If you use alias declarations to merge A.foo and B.foo into one overload
set, yes, you get all the overload problems C++ has. The difference,
though, is that you'll be choosing to get those problems. They will not
happen by accident.
The general philosophy is that D will let you do anything you want to,
including blowing your kneecaps off, but the default behavior will be
fairly safe. You'll have to go to specific, extra work to fire at your
kneecaps. A simple example of this are local declarations:
void foo()
{ int i;
...
)
In C++, i is uninitialized, and contains random garbage. To initialize
it, you must do extra work. In D, i is default initialized to the
default value for type int. You can declare uninitialized variables in D:
int i = void;
but you have to go to extra work to do it. It's not going to happen by
accident. Furthermore, the QA staff can look at such a declaration and
see that it was intentional, and red flag it for further study. Or, they
can mechanically enforce a coding standard that disallows it.
How can you name those modules to import them? In generic code you
don't know to which modules the names belong because the modules
depend on the template parameters.
Ok, I see what you are driving at now. Andrei had discovered that
problem a while back, too. There are a couple of ideas on how to deal
with it. One is to be able to mark a name as "look this name up in the
instantiation context rather than the definition context". Another is to
fashion an equivalence between a.foo(b) and foo(a,b). Then, swap will
become a 'member function' of its first argument. There are various
unattractive workarounds for it at the moment. Certainly, it's a problem
and area of active work.
----
Walter Bright
Digital Mars C, C++, D programming language compilers
http://www.digitalmars.com
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]