PhobosWatch: manifest => enum

[Oskar Linde]

Walter Bright wrote:
> Janice Caron wrote:
>> On 12/28/07, Walter Bright <newshound1 at digitalmars.com> wrote:
>>> Janice Caron wrote:
>>>> y is a /copy/ of x, and clearly it should be possible to make a copy
>>>> of a const thing and have the copy be mutable.

*BEEP* Confusion warning: you mean *constant*, not "const". Huge 
difference. :)

>>> That doesn't work for structs or classes.
>>
>> It doesn't? For structs
>>
>>     struct S {}
>>     const S x;
>>     auto y = x;
> 
> Imagine you have:
>     struct S { int* p; }
> Because const is transitive, const(S) implies that now p points to 
> const. But if you strip off the const in the assignment, you've lost the 
> const-ness of p, and now you have a gaping hole in the const-correctness.

The problem with the current const in D is the lack of orthogonality. As 
far as I can see, those problems would be solved by my orthogonal const 
proposal posted earlier. Constant values (such as structs) are by their 
nature always implicitly convertible to mutable values (worst case: just 
make a copy).

The problem with the current const iteration is that there is no way to 
separate the orthogonal concepts constness (as in constants) from 
read-only access of references.

Also, as far as I can see (not very) there would also not be any need 
for a third type of constant (the manifest one).

const int x = 5;

could behave like a template and only be instantiated when the address 
of x is taken.

The result would be a const design, equally powerful but without 
spoiling the beauty and simplicity of the D1.0 const. In D1.0, when 
something is *constant*, you simply declare it as const:

struct T {
	const int a = 5;
	int b;
}

static assert(T.sizeof == int.sizeof);

No need to stop and think. In D2.0 it seems like you have to go through: 
"Hmm, this value will never change. I will mark it as const.... no wait 
invariant... or maybe manifest constant using the enumeration hack?"

-- 
Oskar