I would like to discuss one of my previous ideas again
as it seems it was lost in the fire.

I think below is the best compromise we can get. In fact
as more I am looking on it as more I am sure that it
not even compromise - it is "well done immutables".

Idea is to extend typesystem with a new type: immutable (const, readonly)
array and pointer.

Proposed notation of immutable array type is as:

     typename#[]

Proposed notation of immutable pointer is as:

     typename#*

Immutable array as a type has exactly the same set
of properties and methods as array except of mutators:

     opIndexAssign and
     int length(int newlength)

Casting rules between array#[] and array[] are obvious:

char#[] is1;
char[] s1;

is1 = s1; // ok.
s1 = is1; // compile time (CT) err.

Examples:

s1[0] = 'a'; // ok
is1[0] = 'a'; // CT err.

s1.length =  1; // ok
is1.length = 1; // CT err.
--------------------------------
String and array literals are immutable by definition:

char#[] slit1 = "Hello world"; // ok
char[] s1 = "Hello world"; // CT err.

Sidenote:
    In C++, by historical reasons, string literals
    have type char* and not const char* which is
    imho bad and needs to be changed.

------------------------------

This approach will give us readonlyness without major changes in language notation and architecture.

This approach is free from C++ "const syntactical madness" where const is used for three different things and looks ugly sometimes.

Clear differentiation of built-in reference types (array and struct) onto
mutable and immutable versions will increase "fullness" of D's
balanced type system.

The thing is that char[] is from one side is atomic type
and it is pretty natural to human to interpret it as just lets say
atomic int. But at the same time it is a reference to some
possibly shared data. This is why arrays and pointers shall
exist in two forms.

As a rule char[] is buffer/owner and char#[] is an immutable slice -
consumer has no rights to change it as it will damage
integrity state of the owner.

-------------------------------------------
Possible variations of immutable type notation I've considered:

1) typename#[]
2) typename$[]
3) typename@[]
4) typename[] const - not good as it conflicts with
                                     C++ cases visually.

typename#[] probably is not the best variant
of notation though. Ideas anyone?

--------------------------------------------
I think it makes sense to add opSliceConst to the list of overloadable operators.
--------------------------------------------

Having readonlyness interpreted and implemented
this way will finally reconcile const and no-const camps. I hope.

Andrew.

Yep, good idea. But you're not the first, and I think not the last who suggest some solution for constness. To me suggestion seems to be ignored.

-- 
Victor (aka nail) Nakoryakov
nail-mail<at>mail<dot>ru

Krasnoznamensk, Moscow, Russia

Not a bad idea. I prefer the solution I've mentioned a few times already.
I just hope Walter gives us some indication of what he's thinking at some stage.
(hint, hint)

Regan

On Wed, 29 Jun 2005 23:06:12 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:

> I would like to discuss one of my previous ideas again
> as it seems it was lost in the fire.
>
> I think below is the best compromise we can get. In fact
> as more I am looking on it as more I am sure that it
> not even compromise - it is "well done immutables".
>
> Idea is to extend typesystem with a new type: immutable (const, readonly)
> array and pointer.
>
> Proposed notation of immutable array type is as:
>
>      typename#[]
>
> Proposed notation of immutable pointer is as:
>
>      typename#*
>
> Immutable array as a type has exactly the same set
> of properties and methods as array except of mutators:
>
>      opIndexAssign and
>      int length(int newlength)
>
> Casting rules between array#[] and array[] are obvious:
>
> char#[] is1;
> char[] s1;
>
> is1 = s1; // ok.
> s1 = is1; // compile time (CT) err.
>
> Examples:
>
> s1[0] = 'a'; // ok
> is1[0] = 'a'; // CT err.
>
> s1.length =  1; // ok
> is1.length = 1; // CT err.
> --------------------------------
> String and array literals are immutable by definition:
>
> char#[] slit1 = "Hello world"; // ok
> char[] s1 = "Hello world"; // CT err.
>
> Sidenote:
>     In C++, by historical reasons, string literals
>     have type char* and not const char* which is
>     imho bad and needs to be changed.
>
> ------------------------------
>
> This approach will give us readonlyness without major changes
> in language notation and architecture.
>
> This approach is free from C++ "const syntactical madness" where
> const is used for three different things and looks ugly sometimes.
>
> Clear differentiation of built-in reference types (array and struct) onto
> mutable and immutable versions will increase "fullness" of D's
> balanced type system.
>
> The thing is that char[] is from one side is atomic type
> and it is pretty natural to human to interpret it as just lets say
> atomic int. But at the same time it is a reference to some
> possibly shared data. This is why arrays and pointers shall
> exist in two forms.
>
> As a rule char[] is buffer/owner and char#[] is an immutable slice -
> consumer has no rights to change it as it will damage
> integrity state of the owner.
>
> -------------------------------------------
> Possible variations of immutable type notation I've considered:
>
> 1) typename#[]
> 2) typename$[]
> 3) typename@[]
> 4) typename[] const - not good as it conflicts with
>                                      C++ cases visually.
>
> typename#[] probably is not the best variant
> of notation though. Ideas anyone?
>
> --------------------------------------------
> I think it makes sense to add opSliceConst to the list of
> overloadable operators.
> --------------------------------------------
>
> Having readonlyness interpreted and implemented
> this way will finally reconcile const and no-const camps. I hope.
>
> Andrew.
>
>

Andrew Fedoniouk wrote:

> typename#[] probably is not the best variant
> of notation though. Ideas anyone?
> 
> --------------------------------------------
> I think it makes sense to add opSliceConst to the list of
> overloadable operators.
> --------------------------------------------
> 
> Having readonlyness interpreted and implemented
> this way will finally reconcile const and no-const camps. I hope.
> 
> Andrew.
> 
> 
I like it and I agree 100%.  I don't happen to like # as the token to signify immutability though.  I've never been opposed to longish names, so my vote would be for "immutable" as a decorator.

immutable char[] is1;
char[] s1;

Brad

And since it has been suggested so many times and IMO a very worth while idea/feature, if Walter does not want to add it, then we need some practices/idioms for D on how to simulate it.

-Kramer

In article <opss6iqfje23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>Not a bad idea. I prefer the solution I've mentioned a few times already.
>I just hope Walter gives us some indication of what he's thinking at some
>stage.
>(hint, hint)
>
>Regan
>
>On Wed, 29 Jun 2005 23:06:12 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>
>> I would like to discuss one of my previous ideas again
>> as it seems it was lost in the fire.
>>
>> I think below is the best compromise we can get. In fact
>> as more I am looking on it as more I am sure that it
>> not even compromise - it is "well done immutables".
>>
>> Idea is to extend typesystem with a new type: immutable (const, readonly)
>> array and pointer.
>>
>> Proposed notation of immutable array type is as:
>>
>>      typename#[]
>>
>> Proposed notation of immutable pointer is as:
>>
>>      typename#*
>>
>> Immutable array as a type has exactly the same set
>> of properties and methods as array except of mutators:
>>
>>      opIndexAssign and
>>      int length(int newlength)
>>
>> Casting rules between array#[] and array[] are obvious:
>>
>> char#[] is1;
>> char[] s1;
>>
>> is1 = s1; // ok.
>> s1 = is1; // compile time (CT) err.
>>
>> Examples:
>>
>> s1[0] = 'a'; // ok
>> is1[0] = 'a'; // CT err.
>>
>> s1.length =  1; // ok
>> is1.length = 1; // CT err.
>> --------------------------------
>> String and array literals are immutable by definition:
>>
>> char#[] slit1 = "Hello world"; // ok
>> char[] s1 = "Hello world"; // CT err.
>>
>> Sidenote:
>>     In C++, by historical reasons, string literals
>>     have type char* and not const char* which is
>>     imho bad and needs to be changed.
>>
>> ------------------------------
>>
>> This approach will give us readonlyness without major changes in language notation and architecture.
>>
>> This approach is free from C++ "const syntactical madness" where const is used for three different things and looks ugly sometimes.
>>
>> Clear differentiation of built-in reference types (array and struct) onto
>> mutable and immutable versions will increase "fullness" of D's
>> balanced type system.
>>
>> The thing is that char[] is from one side is atomic type
>> and it is pretty natural to human to interpret it as just lets say
>> atomic int. But at the same time it is a reference to some
>> possibly shared data. This is why arrays and pointers shall
>> exist in two forms.
>>
>> As a rule char[] is buffer/owner and char#[] is an immutable slice -
>> consumer has no rights to change it as it will damage
>> integrity state of the owner.
>>
>> -------------------------------------------
>> Possible variations of immutable type notation I've considered:
>>
>> 1) typename#[]
>> 2) typename$[]
>> 3) typename@[]
>> 4) typename[] const - not good as it conflicts with
>>                                      C++ cases visually.
>>
>> typename#[] probably is not the best variant
>> of notation though. Ideas anyone?
>>
>> --------------------------------------------
>> I think it makes sense to add opSliceConst to the list of overloadable operators.
>> --------------------------------------------
>>
>> Having readonlyness interpreted and implemented
>> this way will finally reconcile const and no-const camps. I hope.
>>
>> Andrew.
>>
>>
>

Andrew Fedoniouk wrote:
> I would like to discuss one of my previous ideas again
> as it seems it was lost in the fire.
> 
> I think below is the best compromise we can get. In fact
> as more I am looking on it as more I am sure that it
> not even compromise - it is "well done immutables".
> 
> Idea is to extend typesystem with a new type: immutable (const, readonly)
> array and pointer.
> 
Do you think that class/struct types should also be able to be immutable?  Or does that open a can of worms that is too large?  I think that perhaps they should be allowed to be decorated with "immutable", but I am not certain of the rules that should go along with it - ie, what members can be called etc.

I don't really care about this, but it is good to be consistant.  Of course, it will probably be a miracle if Walter gives us a straight answer on your original proposal even :)

Brad

"Brad Beveridge" <brad@somewhere.net> wrote in message news:da13eo$1ao3$2@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>
>> typename#[] probably is not the best variant
>> of notation though. Ideas anyone?
>>
>> --------------------------------------------
>> I think it makes sense to add opSliceConst to the list of overloadable operators.
>> --------------------------------------------
>>
>> Having readonlyness interpreted and implemented
>> this way will finally reconcile const and no-const camps. I hope.
>>
>> Andrew.
>>
>>
> I like it and I agree 100%.  I don't happen to like # as the token to signify immutability though.  I've never been opposed to longish names, so my vote would be for "immutable" as a decorator.
>
> immutable char[] is1;
> char[] s1;
>

In fact immutable arrays are 80% or so of use
cases of arrays in average code.
So motivation is to make 'immutable' flag as
shorter as possible.

What about this:  char![]

Ideally, default char[] should be immutable
and char![] should be mutable.

Andrew.

Andrew Fedoniouk wrote:
> "Brad Beveridge" <brad@somewhere.net> wrote in message news:da13eo$1ao3$2@digitaldaemon.com...
> 
>>Andrew Fedoniouk wrote:
>>
>>
>>>typename#[] probably is not the best variant
>>>of notation though. Ideas anyone?
>>>
>>>--------------------------------------------
>>>I think it makes sense to add opSliceConst to the list of
>>>overloadable operators.
>>>--------------------------------------------
>>>
>>>Having readonlyness interpreted and implemented
>>>this way will finally reconcile const and no-const camps. I hope.
>>>
>>>Andrew.
>>>
>>>
>>
>>I like it and I agree 100%.  I don't happen to like # as the token to signify immutability though.  I've never been opposed to longish names, so my vote would be for "immutable" as a decorator.
>>
>>immutable char[] is1;
>>char[] s1;
>>
> 
> 
> In fact immutable arrays are 80% or so of use
> cases of arrays in average code.
> So motivation is to make 'immutable' flag as
> shorter as possible.
> 
> What about this:  char![]
> 
> Ideally, default char[] should be immutable
> and char![] should be mutable.
> 
> Andrew.
> 
I could see possible problems with templates using !
I agree that having a short flag is probably a good idea, but I would personally value absolute clarity over conciseness.
Some other choices for "immutable"
http://thesaurus.reference.com/search?q=immutable
I like "fixed", "stable", "firm" and "solid" in that order.  Of course, step 1 is getting Walter to agree that we need _something_

Brad

"Brad Beveridge" <brad@somewhere.net> wrote in message news:da1534$1cik$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
>> I would like to discuss one of my previous ideas again
>> as it seems it was lost in the fire.
>>
>> I think below is the best compromise we can get. In fact
>> as more I am looking on it as more I am sure that it
>> not even compromise - it is "well done immutables".
>>
>> Idea is to extend typesystem with a new type: immutable (const, readonly)
>> array and pointer.
>>
> Do you think that class/struct types should also be able to be immutable? Or does that open a can of worms that is too large?  I think that perhaps they should be allowed to be decorated with "immutable", but I am not certain of the rules that should go along with it - ie, what members can be called etc.

If it is needed anyone can create mutable/immutable state
variable for his/her own class. Or create mutable versions
of it. This approach was used in mango.
A bit overkill, IMO, but works.

This # stuff is needed because you cannot override
behavior of basic types.

>
> I don't really care about this, but it is good to be consistant.  Of course, it will probably be a miracle if Walter gives us a straight answer on your original proposal even :)

Hope dies last.

And I think we are almost at position to
start "Sic transit gloria mundi..."

Just wanted to put in my vote for this suggested feature. Whatever the actual syntax ends up being (const / immutable / typename#[] / etc.), we definitely need this. It's up to Walter now, I guess.

Cheers,
--AJG.

PS: Using hackish class-wrappers for this kind of thing is _way_ too much trouble and it not worth it IMHO. We need language/compiler level support.


In article <da024r$65o$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>I would like to discuss one of my previous ideas again
>as it seems it was lost in the fire.
>
>I think below is the best compromise we can get. In fact
>as more I am looking on it as more I am sure that it
>not even compromise - it is "well done immutables".
>
>Idea is to extend typesystem with a new type: immutable (const, readonly)
>array and pointer.
>
>Proposed notation of immutable array type is as:
>
>     typename#[]
>
>Proposed notation of immutable pointer is as:
>
>     typename#*
>
>Immutable array as a type has exactly the same set
>of properties and methods as array except of mutators:
>
>     opIndexAssign and
>     int length(int newlength)
>
>Casting rules between array#[] and array[] are obvious:
>
>char#[] is1;
>char[] s1;
>
>is1 = s1; // ok.
>s1 = is1; // compile time (CT) err.
>
>Examples:
>
>s1[0] = 'a'; // ok
>is1[0] = 'a'; // CT err.
>
>s1.length =  1; // ok
>is1.length = 1; // CT err.
>--------------------------------
>String and array literals are immutable by definition:
>
>char#[] slit1 = "Hello world"; // ok
>char[] s1 = "Hello world"; // CT err.
>
>Sidenote:
>    In C++, by historical reasons, string literals
>    have type char* and not const char* which is
>    imho bad and needs to be changed.
>
>------------------------------
>
>This approach will give us readonlyness without major changes in language notation and architecture.
>
>This approach is free from C++ "const syntactical madness" where const is used for three different things and looks ugly sometimes.
>
>Clear differentiation of built-in reference types (array and struct) onto
>mutable and immutable versions will increase "fullness" of D's
>balanced type system.
>
>The thing is that char[] is from one side is atomic type
>and it is pretty natural to human to interpret it as just lets say
>atomic int. But at the same time it is a reference to some
>possibly shared data. This is why arrays and pointers shall
>exist in two forms.
>
>As a rule char[] is buffer/owner and char#[] is an immutable slice -
>consumer has no rights to change it as it will damage
>integrity state of the owner.
>
>-------------------------------------------
>Possible variations of immutable type notation I've considered:
>
>1) typename#[]
>2) typename$[]
>3) typename@[]
>4) typename[] const - not good as it conflicts with
>                                     C++ cases visually.
>
>typename#[] probably is not the best variant
>of notation though. Ideas anyone?
>
>--------------------------------------------
>I think it makes sense to add opSliceConst to the list of overloadable operators.
>--------------------------------------------
>
>Having readonlyness interpreted and implemented
>this way will finally reconcile const and no-const camps. I hope.
>
>Andrew.
>
>

=======================
I sync, therefore I am.