D const design rationale

[Oskar Linde]

Walter Bright skrev:
> OF wrote:
>> Walter Bright Wrote:
>>
>>> BLS wrote:
>>>> I am afraid you will not like this idea, but not afraid enough. <g>
>>>>
>>>> Why not using a single keyword "const_" adding a number 1, 2, 3 to 
>>>> represent :
>>>> invariant, final, readonlyview.
>>>> the higher the number the higher (the stronger) the const.
>>>> means : const_3 == invariant;
>>>> At least a mental help, IMO; somehow borrowed from Modula 2 processes.
>>> You're right, I don't like the idea <g>.
>>
>> I'm curious. Was 'readonly'
> 
> readonly is a synonym for const, so no improvement there.

Read-only isn't synonymous with constant. The etymology of constant is 
from latin constare, which means "to stand firm". The most common 
meaning of 'constant' is 'unchanging'. It also has a well defined 
mathemathical meaning that is quite far from read-only.

It is perfectly valid to talk about read-only access, read-only 
registers, read-only properties, read-only pins, etc without any of them 
being considered constant. In all those cases, D 2.0's current 'const' 
fits perfectly.

Some examples:

A A/D unit on a device may be read by reading a io mapped memory 
register. The register is certainty read-only, but no one would call it 
constant.

The Instruction Counter on may microprocessors can be read but may 
seldom be written to directly. It is certainly read-only, but definitely 
not constant.

You may only be allowed a read-only view of a file. Other processes can 
modify the file so it can't be considered constant (unchanging).

> readonlyview is too long.

Agreed.

/Oskar