downs wrote: > 1) If it's a word, put it in the standard library. > 2) Otherwise, put it in the compiler.
What an interesting theory. > For example: > > assert() -> library. Compile-time proof of assertion/contract correctness would be far more problematic. > complex -> library. > void -> C-derived, compiler. I believe void should be a typedef of the empty type-tuple. That would be library. > real -> C-derived via long float, compiler. > cfloat -> library. > for -> compiler. Might as well put this one in a library, since it's easy to simulate with a while-loop. The only reason D can't is that, as far as I know, it doesn't support trailing delegate literals after a function-call, that fill the role of its last actual parameter. > foreach -> library. Perhaps. But that would make static analysis more problematic. > T[] -> compiler. I'd rather see dynamic arrays in a library. A template class that overloads the T[] notation. Isn't it true that programmers don't have any control over the allocation strategies and such of the built-in data-structures? > T.dup, T.sort, T.reverse -> library. Agreed on that one. But what about these: const immutable class struct typedef template ref shared Well, you get the point. It turns out to be a bit of a silly rule, doesn't it? Perhaps you meant: "If it's a word, put it in the standard library, unless it belongs in the core language." :-) -- Michiel Helvensteijn