Interested in D, spec confuses me.

[Bambi via Digitalmars-d]

I have to disclaim that I am not a very good programmer, and I am 
doing this on a hobby level.

I'm reading through the spec because D seems to be a very 
interesting language that affords lower level control than say C# 
without the syntactical mess of C++. A few things confuse me a 
lot.

1. const isn't constant
  To my mind, a const is a value that cannot change from the 
moment it is defined. But D allows for modification of const 
values through non-const references and pointers, and does not 
promise to optimize const by placing it in read only memory or 
similar. Instead, it provides immutable, which does promise an 
constant value throughout the lifetime of the value. I'm not sure 
why this distinction was created, or what const is supposed to 
accomplish here. It's just very confusing to have two keywords 
that intuitively do the same thing but don't really. Applying 
these keywords to methods would seem to make the data of the 
parent object immutable to only the function. Which might be 
useful but isn't immediately obvious from the written form.

The example snippet ' immutable(int[]) bar() immutable {} ' 
brings back bad memories of redundant declarations of the style ' 
Object object = new Object(); '. And homonyms in programming 
languages seem like a bad idea in general.

2. when is an extern an extern?
  The wiki page on interfacing with C states that C globals 
require an extra extern. The extern definition in the spec 
clarifies that extern(C) alone will copy the global into the 
current module, but that extern extern(C) will read it right from 
the C code. Or maybe it means to say that using extern(C) alone 
will only specify a different calling convention for the variable 
you are declaring. It's honestly not clear. Homonym problem again.

3. typeof is an operator, sizeof is a property
  ...but not really :^). It seems like these are similar, they 
give compile time information about the object you pass them, but 
one is implemented as a function-looking operator in the classic 
C style while another is trying to mimic member access. It lacks 
consistency. And confuses as to what is a member and what isn't. 
Let the period operator be reserved for real member access and 
other operators be their own thing.

That's all for now. I don't really understand these choices. They 
seem to only confuse rather than clarify.