A simple rule

[downs]

Michiel Helvensteijn wrote:
> 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.
> 

Well to be fair, we don't do that anyway.

>> complex -> library.
>> void -> C-derived, compiler.
> 
> I believe void should be a typedef of the empty type-tuple. That would be
> library.
> 

I honestly didn't think of that.

>> 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.
> 

I mainly inserted the "C-derived stuff in the language" rule so we'd have a set of primitives. The problem with for is that it has a fixed syntax that would require more than a few changes to D .. trailing delegate alone wouldn't cut it, you'd need a way to specify a fully extensible syntax and we'll probably never have that.

>> foreach -> library.
> 
> Perhaps. But that would make static analysis more problematic.
> 

Inlining ~

>> 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?
> 

As I understand, D will probably never have the extensible syntax necessary to support that.

No, strictly speaking it's not _quite_ true. Arrays can be wrapped over existing pointers; these pointers can be acquired using any strategy you want. Of course, appending and such will move it back into GC space :)

>> 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." :-)
> 

Actually, I qualified that in another post .. it's meant more as a fallback when there aren't compelling reasons to put it in the compiler.

Thanks for the response!