Re: How `export' could be useful
Walter Bright wrote:
Andrei Alexandrescu (See Website For Email) wrote:
Walter Bright wrote:
But D can do it differently. Preparsing works in D template bodies
because the language is designed to be parseable without semantic
knowledge. The semantic analysis is done at instantiation time.
My opinion is a bit different. To summarize it: it's best to do
semantic
analysis (the more the better) when seeing the template body. It's bad
that C++ needs semantics just to be able to parse.
Being able to parse the template bodies is not that big a deal in and of
itself, the important thing is to parse it at some point at compile
time. When in the compilation process it is done doesn't really matter.
The big deal, however, in being able to parse without a symbol table is
that one can write tools that can analyze source code without having to
build a full blown compiler. Being able to parse the code *correctly*
without needing to spend 10 years first building a compliant front end
opens up a big door to all kinds of tools that can be written that can
manipulate source code.
This is a misunderstanding. I agree with everything you've said, but it
does not address anything of what I said.
Ideally, it should be enough for a compiler to see a template
definition
to figure out the following:
(1) What exact requirements a type is expected to meet to be proper
for
instantiating the template;
(2) Which parts of the template impose each of those requirements.
Point 1 is necessary for separate compilation, point 2 is necessary
for
meaningful error messages (that could also help the template author to
relax the requirements).
I think the requirements a template parameter should meet (i.e.
"constraints") should be specified by the template author in the
interface to the template (analogously to how function parameter types
must be explicit). Having the compiler figure them out for you I'm not
sure of the utility of.
So you don't need to invent syntax for the constraints, among other
things. Much like type deduction, if it's something that the compiler
can do better than the human, let the compiler do it. I admit I'm
ambivalent about that. Sometimes it's better to have the human sit down
and figure out the constraints in advance.
So if D defers all of the hard work to instantiation time,
Ironically, in C++ parsing is the hard part. In D, parsing is the easy
part <g>.
paint me unimpressed. That's just C++ cleaned of the C-inherited
ambiguities that
led to the "typename" ab(d)omination.
Fixing the name lookup rules is far from the only thing improved in D
templates. My aim is to make templates as easy to write as ordinary
classes or functions are - cleaning up the syntax and the rules is a
necessary step for that. Templates should be writable by mortals, not
just the gods <g>.
That's all good, but hard to quantify such fuzzy aims and to measure
progress. I'm big on reining in and finding measures. One measure is
exactly what I said: to what extent can you compile a template
separately? D's answer seem to be: nothing beyond parsing. We parse the
thing and store the AST for later use. I believe that that's the wrong
answer, one that takes the language astray from the goal of making it
easy to write templates.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]