Const sucks

[Steven Schveighoffer]

Overall, I like this solution MUCH better than before.  I have some points 
to make, but let me say thanks for working on this and taking everyone's 
opinion into account.

"Walter Bright" wrote
> Const, final, invariant, head const, tail const, it's grown into a 
> monster. It tries to cover all the bases, but in doing so is simply not 
> understandable.

Hear hear.

> o  const and invariant now mean "fully const" and "fully invariant", where 
> fully means "head and tail combined":
>
> const int x = 0;   // x is constant
> const int* p = &x;  // neither p nor *p can be changed
> const(int*) p = &x;  // neither p nor *p can be changed
> const(int)* p = &x;  // p can change, *p cannot be changed

What about const(int) x = 0?  I'm guessing the same as const int x = 0?
Is it safe to say that const(T) x is equivalent to const T x?  What about 
classes?

> o  tail const of a struct would have to be done by making the struct a 
> template:
>
>   struct S(T) { T member; }
>   S!(int)   // tail mutable
>   S!(const(int)) // tail const
>

I didn't see it brought up by anyone else, so I'll ask.  Did you mean:
struct S(T) { T * member; }
???

Because I always thought tail const had to do with pointers.  If not, can 
someone please explain the difference between the two structs in Walter's 
example?

> o  one can construct a template to generically produce tail const or tail 
> invariant versions of a type.

This prevents casting, which from what I can interpret from the previous 2.0 
proposal (the monster), you could do.

i.e.

struct MyNiftyPointer(T) {T * ptr; int someOtherCoolValue;}

void myGreatFunction(MyNiftyPointer!(const(int)) x)
{
  // do something that doesn't modify *x.ptr
}

void test()
{
  MyNiftyPointer!(int) p;
  // set up p
  ...
  myGreatFunction(p); // will this compile?
}

Not that I really care much.  You may be able to implement an opImplicitCast 
that worked around this problem.  Really, I only see this feature being 
useful for a smart-pointer/array type, so I'm pretty sure I'll never use it.

> o  So, we still need a method to declare a constant that will not consume 
> memory. We'll co-opt the future macro syntax for that:
>
>     macro x = 3;
>     macro s = "hello";

First, I don't like the syntax.  I understand it's roots, as #define is now 
being replaced by macro, but #define seems a more descriptive keyword than 
macro when trying to define something as being something else.  I agree with 
Daniel Keep when he said he expected alias.

Second, I'm trying to understand what the real purpose of this is.  Could 
someone define the different types of memory and why we need different 
declarations to put things in those different types?  For example, "doesn't 
consume memory" doesn't make sense to me.  The bytes gotta go somewhere!

Third, how would you define constants that are not implicitly typed, like a 
structure?  I can see this being useful for something like a configuration 
table, or a table of CRC values.

-Steve