Const/Shared/Immutable anomalies in D that should be fixed

[Jonathan M Davis]

On Wednesday, May 02, 2012 23:19:40 Mehrdad wrote:
> > Marking a struct's definition as const or immutable just makes all of its
> > members const or immutable.
> > The type itself can't be const or immutable.
> 
> What sense does it make to have a struct whose members are all const, and
> which is not automatically const by itself?

const struct S {}

is basically the same as

const { struct S {} }

and

const: struct S {}

(though the last one affects the rest of the file). It's just part of how 
attributes work. You could do the same with public, private, @safe, nothrow, 
etc. It would just complicate the language to automatically make any variables 
of a struct whose every member is const always const, especially since doing 
the same wouldn't make any sense with most of the rest of the attributes (e.g. 
you can't declare a variable as nothrow). Not to mention, it's generally 
pretty unusable to declare _everything_ in a struct const anyway, so why add a 
special case for it?

- Jonathan M Davis