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!
