"pragma" <pragma_member@pathlink.com> wrote in message news:dskoas$1u2n$1@digitaldaemon.com...
> In article <dsk7ch$qmm$1@digitaldaemon.com>, Andrew Fedoniouk says...
>>
>>>
>>> I'd also like to see 'readonly' used in favor of 'const'.  A 'writable'
>>> modifier
>>> would also make template programming easier, due to its symmetry (see
>>> below)
>>>
>>>> // to summarize the above:
>>>>
>>>> readonly char[] x = "hello world";
>>>> char[] y = cast(char[])x; // Explicit cast from readonly triggers COW
>>>> idiom
>>>>
>>>> y[0..$] = "byebye world"; // legal (working with a copy of x)
>>>> x[0..$] = "byebye world"; // illegal (readonly)
>>>>
>>>> readonly Foobar a = new Foobar(); // illegal: readonly not applicable
>>>> to
>>>> classes
>>>>
>>>> // example of using 'writable' (spoof of the ol' const-cast)
>>>> template(writable T) const_cast{
>>>>   T foobar(readonly T arg){
>>>>     return cast(writable)arg;
>>>>   }
>>>> }
>>>
>>
>>Exactly.
>>
>>Thought about decorations:
>>
>>In phrase 'readonly char[]'  readonly is in fact a part of array type
>>modifier ([])
>>so semanticly speaking it should look like 'char readonly []' -
>>in short : "char #[]" where '#' means exactly "no-assignment allowed".
>>
>>Second one about "Explicit cast from readonly triggers COW idiom"
>>
>>I think that cast should be a cast as it is now.
>>dup is already there for that purposes. No?
>
> I disagree.  Readonly means more than "don't assign to me".  It should
> also
> mean, "the data I point to is protected".  Sure, you could emulate this
> with a
> dup but its much cleaner if it is an assumed operation when casting to and
> from
> readonly*.
>
> One of the pitfalls of the C's const design was that the best that could
> possibly be accomplished by the complier is a static cast.  In D, we have
> a
> garbage collector, so we can automatically enforce the readonly integrity
> of the
> original const data by performing a copy on cast.  This will lead to fewer
> errors and make things more failsafe by strictly maintaining readonly and
> writable sets of data.**
>

Ideally yes, but practically you *will* have situations
when you need to remove 'constness' from particular readonly
data chunk - for example - passing string to some external API and
libraries.

The whole idea of having readonly arrays/pointers - provide declarative readonliness but keep implementation effective as it is.


So instead of:

readonly char[] x = "hello world";
char[] y = cast(char[])x; // Explicit cast from readonly triggers COW

you will write:

readonly char[] x = "hello world";
char[] y = x.dup; // Explicit copy

- more clear I believe.

> Also, the '#' symbol is reserved by the lexer for compiler directives.
> Using it
> in the way you suggest makes D's syntax context-sensitive; something that
> Walter
> has been quite adamant about avoiding.  For instance, how would you expect
> the
> following to compile?
>
>> char
>> #[] foobar;
>
> IMO, we're better off using no-nonsense modifiers like 'readonly' and
> 'writeable' as there's zero room to debate what they actually mean, or how
> to
> parse them.

#* and #[  are single tokens with one character lookahead.
D tokenizer is already doing this stuff everywhere.
!  and !=  , < and <=, + and ++, etc.


>
> * Casting from writable to readonly should also copy as to ensure that
> writable
> and readable data remain distinct and protected.  I'd anticipate that .dup
> on
> array operations would also inherit the parent's readonly/writable
> attributes,
> so slices would have to be cast in a similar way.  This would ensure that
> aliases to readonly data would in themselves be readonly.

Runtime and compiler has no way to enforce "data remain distinct and
protected"
in 100%.

The *only* thing what compiler can verify and enforce is that:

    particular readonly pointer has no operartion "l-value dereferencing"

The same apply to readonly arrays.

It is a task of the same complexity for compiler as to determine if class
Foo
has method Bar - not more.

Other meanings of const and readonly, is a pitty, but just dreams.

>
> ** Of course you can always throw caution to the wind by casting through
> void*,
> which would avoid any copying by not explicitly casting to/from readonly.
>

Andrew.