Re: The D Programming Language
AJ wrote:
Hi there,
James Kanze wrote:
<snip>
That depends. Library support isn't as good as core support
when it isn't as good. The fact that it is library and not core
isn't a disadvantage per se---I'd say that almost the opposite
is true. But you do have to compare the level of support; there
are some things that simply cannot be supported in a library
alone.
I think I agree, though I also think we need a clear definition of a
"library" and of "core-language" support. It is unclear at this
point whether a library can be "magic" in the sense that it does
things a regular user couldn't.
It can be magic, in that the library writer can make a deal with the
compiler writer, to have some formally undefined heaviour actually being
defined for a specific use. Some offsetof macros use that trick.
It is also unclear what is meant by C++ any more. Is C++ simply the
language, or does it include the STL? I don't think I would include
the STL into the definition of the "core" C++ language.
The C++ language is what is included in the standard, all chapters.
snip
Formally, if it is part of the standard library, the compiler
can know about it, and do whatever is necessary. This is often
the case for standard library functions (like memcpy) in C. To
date, it's not become the case for anything in C++, at least to
my knowledge, although the standard certainly allows it. I
think, however, that part of the goal is to design things so
that the compiler can do the job well, not just for standard
components, but for any user defined class.
I think this is what Walter disagrees with. If you're gonna make a
special case for some part of the "standard" library, then why not
make that feature part of the "core" language in the first place?
You get the advantage of nicer syntax and semantics with the
advantage of clean, intrinsic compiler support without having to
"cheat" with a "magic" library (which is what he called the worst
of both worlds).
Requiring compiler support doesn't make a feature clean, it makes it dirty.
I believe that's where James and I disagree with Walter.
If you have a core language support that allows std::string to be
efficiently implemented as a library, that means that other similar classes
can be efficiently implemented as well. By someone other than the compiler
writer.
The fact that it can be done as a library only, with no specific magic,
actually shows that the language is stronger, not weaker.
The fact that Walter designs and implements his own language, puts him in a
different position than most of us. Perhaps that influences his point of
view? Or maybe his views is the reason for doing it?
I am very happy when I can implement, or extend, some feature without
specific compiler support.
Bo Persson
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]