Polishing D - suggestions and comments

[Neal Alexander]

Unknown W. Brackets wrote:
> I thought I might write down some of the many suggestions I have for 
> making D really come into the spotlight as a language.
> 
> They cover many areas, and I'm trying to address issues that I feel 
> aren't being given - by what I've seen - enough attention.  I'm sure 
> many of you here will pick me apart, and I look forward to it.
> 
> Hopefully some of the suggestions can improve D.
> 
> I write these with experience with an open source project I lead the 
> development of, and years of watching the Mozilla development process. I 
> have no doubt that the majority of these things would be of great 
> improvement, if they are possible and done.
> 
> http://www.unknownbrackets.com/tutorials/polishing-d
> 
> -[Unknown]

Having a highly optimized and pluggable GC would go a long way i think.


It seems like sometimes a naive implementation in D can be slower than 
its Java counterpart -- kind of a kick in the teeth IMO. People tend to 
have a false sense of security that stuff will automatically be faster 
because its native compiled.

It wouldn't hurt to have an article explaining the performance 
implications of some of the more exotic features of the language either.



On an unrelated note: i've noticed a *lot* of code tends to use 
templated function parameters for stuff like read()/write() operations. 
This type of usage pattern should probably be supported in a different 
way IMO.

Things to consider (off the top of my head):

**** Avoid template code replication for different types by defining 
common attributes / operations -- some type of numerical interface that 
defines operations for built-in and user types. This doesnt have to mean 
that basic types become real classes but that the compiler knows how to 
generate stubs for each operation.


t_interface ordinal  { void inc(); void plus(ordinal); ... }
t_interface copyable
{
     void* ptr();
     size_t size();
     void copy(copyable);
     ...
}

Side note: Maybe the "copyable" interface could be overloaded to perform 
endian conversion or simple crypto etc.


t_interface number : ordinal, copyable, ...;

type double : number
type int    : number
type char   : ordinal, copyable;

class user_t : number
{
     uint64_t backing;
     size(){ return backing.sizeof; }
     inc(){ ++backing; }
     ...
}

void f(number x){ x.inc; printf("size=%d", x.size); }

double d;
int i;
char c;
user_t t;

f(d); -> size=8
f(i); -> size=4
f(c); -> size=1
f(t); -> size=8


**** Function parameter assignment
double d;
file.read(d, offset=4);

void read(copyable data, size_t offset = void, int flags = 1234){ ... }

("void" used to ignore options instead of hacks like size_t.max would be 
nice)



I dunno, its kind of a half baked idea i guess, but something to consider.