Const template

[Andrei Alexandrescu (See Website For Email)]

Bruno Medeiros wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> Bruno Medeiros wrote:
>>> Andrei Alexandrescu (See Website For Email) wrote:
>>>> Today, Walter and myself have come with a semantics for const (as 
>>>> in, "read-only view" that) seems to be a good starting point. The 
>>>> details are yet to be ironed out, but here's the basic plot:
>>>>
>>>
>>> So the keyword for the "read-only view" will be 'const' too? It will 
>>> share space with the 'const' as in "compile time constant" ?
>>
>> Yes. This is arguably a weak point of the design.
>>
> 
> Indeed. :(  Won't this cause must woe afterwards, so that it should be 
> changed?
> Also will the compile-time const also be a "storage class" (i.e., part 
> of the type)? If so how do we distinguish both? As in, how do we check a 
> types "storage classes":
>   is(typeof(foo) == const) // ?

Yes, the intent is that const is part of the type and that it is detectable.

>> class Widget { ... }
>> auto a = new Widget; // invokes this()
>> auto b = new const Widget; // invokes this(const)()
> 
> Ok, but what is such a const object? Is it an object that actually does 
> not change? (as opposed to simply a read-only view of it?)

It's an object that has no accessible mutating view.

> And what is the difference between a normal delete, and the deletion of 
> a const reference? (the latter doesn't even make sense to me, delete is 
> a mutating operation)

As I said, this is a sticky point. I think the only right semantics is 
to disable deletion.


Andrei