A simple rule

[Michiel Helvensteijn]

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