Thread overview | |||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 30, 2005 Immutable arrays for Walter and rest of us. | ||||
---|---|---|---|---|
| ||||
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. |
June 30, 2005 Re: Immutable arrays for Walter and rest of us. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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
|
June 30, 2005 Re: Immutable arrays for Walter and rest of us. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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.
>
>
|
June 30, 2005 Re: Immutable arrays for Walter and rest of us. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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
|
June 30, 2005 Re: Immutable arrays for Walter and rest of us. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | 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. >> >> > |
June 30, 2005 Re: Immutable arrays for Walter and rest of us. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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
|
June 30, 2005 Re: Immutable arrays for Walter and rest of us. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Beveridge | "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. |
June 30, 2005 Re: Immutable arrays for Walter and rest of us. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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 |
June 30, 2005 Re: Immutable arrays for Walter and rest of us. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brad Beveridge | "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..." |
June 30, 2005 Re: Immutable arrays for Walter and rest of us. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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. |
Copyright © 1999-2021 by the D Language Foundation