www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - To mutate or not to mutate?

reply Matthias Spycher <matthias coware.com> writes:
http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

Does anyone else (Kris?) feel an urgent need for some immutable basic 
data types in D? Especially in light of the recent plan to translate SWT 
-> DWT and possible other Java projects in the future. IMHO D should at 
least provide immutable strings. I'm sure we all agree -- it has been 
discussed before -- that having some light-weight immutable data types 
is a good thing in the context of scalable, multi-threaded, GC-enabled 
programs. Now it just seems more urgent...

Kris, I imagine your translator will be dependent not on just the D 
language, but also a library, right? If so, which one?

Matthias
Feb 08 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Matthias Spycher" <matthias coware.com> wrote in message 
news:dsdc9n$20dh$1 digitaldaemon.com...
 http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

 Does anyone else (Kris?) feel an urgent need for some immutable basic data 
 types in D? Especially in light of the recent plan to translate SWT -> DWT 
 and possible other Java projects in the future. IMHO D should at least 
 provide immutable strings. I'm sure we all agree -- it has been discussed 
 before -- that having some light-weight immutable data types is a good 
 thing in the context of scalable, multi-threaded, GC-enabled programs. Now 
 it just seems more urgent...

The problem with some sort of immutable data type is there are at least a dozen different ways to do it. A lot more thinking has to go into this, less we get stuck with a poor design like C++'s.
Feb 08 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 
 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, less 
 we get stuck with a poor design like C++'s. 

Definately. While I find the idea appealing, I would prefer to approach it carefully. Particularly since the more straightforward approaches (such as making 'const' a logical qualifier) seem likely to break a tremendous amount of code in ways that might not be so easy to fix. Sean
Feb 08 2006
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dsdn6t$289j$3 digitaldaemon.com...
 "Matthias Spycher" <matthias coware.com> wrote in message 
 news:dsdc9n$20dh$1 digitaldaemon.com...
 http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

 Does anyone else (Kris?) feel an urgent need for some immutable basic 
 data types in D? Especially in light of the recent plan to translate 
 SWT -> DWT and possible other Java projects in the future. IMHO D should 
 at least provide immutable strings. I'm sure we all agree -- it has been 
 discussed before -- that having some light-weight immutable data types is 
 a good thing in the context of scalable, multi-threaded, GC-enabled 
 programs. Now it just seems more urgent...

The problem with some sort of immutable data type is there are at least a dozen different ways to do it. A lot more thinking has to go into this, less we get stuck with a poor design like C++'s.

I would rise this question again: Is it possible to declare (typedef) new array type with all mutating methods disabled? Sort of: typedef char[] string ( no opIndexAssign; no void length(int) ) This will be pretty sufficient for strings and other cases. In any case ability to create new types from intrinsic types is a good thing in D. But it is a half. It should be a mechanism of declaring also set of operations allowed. Again, array as a builtin feature lacks their immutable counterparts in D typesystem. Andrew.
Feb 08 2006
parent reply Sean Kelly <sean f4.ca> writes:
Andrew Fedoniouk wrote:
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:dsdn6t$289j$3 digitaldaemon.com...
 "Matthias Spycher" <matthias coware.com> wrote in message 
 news:dsdc9n$20dh$1 digitaldaemon.com...
 http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

 Does anyone else (Kris?) feel an urgent need for some immutable basic 
 data types in D? Especially in light of the recent plan to translate 
 SWT -> DWT and possible other Java projects in the future. IMHO D should 
 at least provide immutable strings. I'm sure we all agree -- it has been 
 discussed before -- that having some light-weight immutable data types is 
 a good thing in the context of scalable, multi-threaded, GC-enabled 
 programs. Now it just seems more urgent...

dozen different ways to do it. A lot more thinking has to go into this, less we get stuck with a poor design like C++'s.

I would rise this question again: Is it possible to declare (typedef) new array type with all mutating methods disabled? Sort of: typedef char[] string ( no opIndexAssign; no void length(int) ) This will be pretty sufficient for strings and other cases.

const char[] ar = "hello world"; char* c = &ar[0]; c = 'j'; I grant that it's a corner case, but worth noting nevertheless. Sean
Feb 08 2006
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 I would rise this question again:

 Is it possible to declare (typedef) new array type with all mutating 
 methods disabled?
 Sort of:
 typedef char[] string ( no opIndexAssign; no void length(int) )

 This will be pretty sufficient for strings and other cases.

const char[] ar = "hello world"; char* c = &ar[0]; c = 'j'; I grant that it's a corner case, but worth noting nevertheless.

In C++ I am enabling: T operator [] and disabling: T& operator [] in such cases. But as you said "it's a corner case". cast() is there and you may do scarry things with it and this is not an argument to disable raw cast in the language, right? Andrew.
Feb 08 2006
prev sibling next sibling parent Matthias Spycher <matthias coware.com> writes:
I agree, it's not an easy task in general. But a simple final String 
class that prevents (as much as possible) all direct access to the 
underlying array of characters in its API would go a long way already, 
no? If the API exposed only dchar values (for accessing individual 
characters), you would not expose the actual implementation, which might 
be optimized during construction.

Immutability implies sharing, so these objects are more likely to be 
allocated on the heap, and I imagine the garbage collector could provide 
an interning service for them.

The implementation of java.lang.String has evolved quite a bit over the 
years, despite the fact that it deals with only one type of char. I 
don't expect the evolution of a D.String to be any different. Certainly, 
having minimal support for immutable strings in D 1.0 has to be better 
than no support at all.

Matthias

Walter Bright wrote:
 
 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, less 
 we get stuck with a poor design like C++'s. 
 
 

Feb 08 2006
prev sibling next sibling parent reply "Charles" <noone nowhere.com> writes:
I'd like to add that from my 6 years with C++, I have never been _saved_ (
to my knowledge -- knock on wood ) by const.  And I must have typed it
thousands of times .

Not that Im voting against immutability, only that if it does get added its
as non-intrusive as possible.  But I really don't want to start another
debate!

Charlie

"Walter Bright" <newshound digitalmars.com> wrote in message
news:dsdn6t$289j$3 digitaldaemon.com...
 "Matthias Spycher" <matthias coware.com> wrote in message
 news:dsdc9n$20dh$1 digitaldaemon.com...
 http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

 Does anyone else (Kris?) feel an urgent need for some immutable basic


 types in D? Especially in light of the recent plan to translate SWT ->


 and possible other Java projects in the future. IMHO D should at least
 provide immutable strings. I'm sure we all agree -- it has been


 before -- that having some light-weight immutable data types is a good
 thing in the context of scalable, multi-threaded, GC-enabled programs.


 it just seems more urgent...

The problem with some sort of immutable data type is there are at least a dozen different ways to do it. A lot more thinking has to go into this,

 we get stuck with a poor design like C++'s.

Feb 09 2006
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Charles" <noone nowhere.com> wrote in message 
news:dsfnlr$247h$1 digitaldaemon.com...
 I'd like to add that from my 6 years with C++, I have never been _saved_ (
 to my knowledge -- knock on wood ) by const.  And I must have typed it
 thousands of times .

 Not that Im voting against immutability, only that if it does get added 
 its
 as non-intrusive as possible.  But I really don't want to start another
 debate!

Well it is different point of view and it is perfectly valid. For you and for me. The thing is simple: const is a declartion - meta information if you wish. const is more collaborative tool than probably anything else. It is seems like for Walter too - const worth nothing because he is working on his own codebase and he knows *his own* code very well. But we have completely different story in team projects. See, partner developers from China will send us class: class Record { Field[] fields(); } Do you have any idea of how you can use this fields? Can you change fieldset or not? Again, for a lone-code-wolf writing 50000 lines code in three months const is (probably) just nothing if not worse - more chars to type. For the team it is a way to reduce needed documentation for example - quite opposite to your situation. C++ and C99 has "char[]" and "const char[]" which are two distinct types. D has only one char[]. Step back? Yes. Again, it seems that having readonly array type (like char#[] ) will allow to reduce problem significantly. For classes and objects you can create readonly envelopes, but arrays are naked in this regard. You can create as many meta programming features as you wish but without such basic feature your type system is just Andrew.
Feb 09 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Andrew Fedoniouk wrote:
 
 For the team it is a way to reduce needed documentation for example - quite
 opposite to your situation.
 
 C++ and C99 has "char[]" and "const char[]" which are  two distinct types.

Frankly, I have far more problems with people just not writing meaningful code. For example: class C { public: Thing* getThing(); }; Who owns the Thing returned by C? And is Thing even dynamically allocated? auto_ptr was designed for this purpose, but no seems to use it correctly: class C { public: std::auto_ptr<Thing> getThing(); }; Here, the transferral of ownership indicated by the syntax, as is the fact that Thing was allocated on the heap. The same could be said of const qualifiers. In my experience, little thought often goes into what is made 'const' and what isn't, and deciphering this later is a maintenance nightmare. Pointers are another problem area, as many people don't seem aware that "int const *const" is a legal statement, or know what the position of each 'const' implies. In summary, I agree that 'const' can be useful in Ivory Tower type programming. But unfortunately, I seem to keep being called out to the docks. If someone can come up with a form of immutability that is both elegant and meaningful I'll be cheering for its inclusion in D. But I'm beginning to agree with Walter that the C++ implementation can deceptive, which greatly reduces its utility. Sean
Feb 09 2006
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:dsgie6$2lap$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:
 For the team it is a way to reduce needed documentation for example - 
 quite
 opposite to your situation.

 C++ and C99 has "char[]" and "const char[]" which are  two distinct 
 types.

Frankly, I have far more problems with people just not writing meaningful code. For example: class C { public: Thing* getThing(); }; Who owns the Thing returned by C? And is Thing even dynamically allocated? auto_ptr was designed for this purpose, but no seems to use it correctly: class C { public: std::auto_ptr<Thing> getThing(); };

Let's say you need to create bullet-proof library of the things Then it is just enough to declare: class Thing { package ~this(); } Having this no one auto_ptr will accept it and user will get an idea that this Thing is managed by Things package. No documentation needed and compiler will enforce this.
 Here, the transferral of ownership indicated by the syntax, as is the fact 
 that Thing was allocated on the heap.

Yep, "Show me your destructor and I will tell you what policy do you use"
 The same could be said of const qualifiers.  In my experience, little 
 thought often goes into what is made 'const' and what isn't, and 
 deciphering this later is a maintenance nightmare.  Pointers are another 
 problem area, as many people don't seem aware that "int const *const" is a 
 legal statement, or know what the position of each 'const' implies.

I understand that this const * (const *) notation in C++ is just a ... you know what. Trust me, I understand Walter's concerns and know them too well.
 In summary, I agree that 'const' can be useful in Ivory Tower type 
 programming.  But unfortunately, I seem to keep being called out to the 
 docks.  If someone can come up with a form of immutability that is both 
 elegant and meaningful I'll be cheering for its inclusion in D.  But I'm 
 beginning to agree with Walter that the C++ implementation can deceptive, 
 which greatly reduces its utility.

Let me remind that idea of "practical immutability" again: 1) Now in D any user type (structure, class) can be designed to be explictly immutable - if you want some class of the package be immutable outside - declare all its mutating methods with package attribute. Simple and is already there. 2) arrays. array is a builtin *structure* in D with its own set of operations: There is no mechanism in D to declare readonly array. Proposals: a) to introduce readonly array type e.g. as type#[]. b) -or- provide another way (e.g. extended typedef) to explicily list operations allowed on the array type. 3) pointers. The same problem and similar solution: Introduce new readonly pointer type, e.g. #* e.g. type#* rop; so *rop cannot serve l-value purposes. Implementation is simple, notation is simple - can be implemented reliably. Andrew Fedoniouk. http://terrainformatica.com
Feb 09 2006
prev sibling parent Matthias Spycher <matthias coware.com> writes:
As much as I like the notion of immutable arrays, it is a tough 
proposition in a language that directly exposes memory to the programmer 
using pointers.

For an object-oriented language with a GC, I would propose a class-based 
solution for immutable objects. They are good candidates for sharing, so 
allocation on the heap will be frequent. In other words, the class 
overhead is justifiable.

I think I'm on Walter's side regarding const; also for simplicity's sake.

Matthias

Andrew Fedoniouk wrote:
 "Charles" <noone nowhere.com> wrote in message 
 news:dsfnlr$247h$1 digitaldaemon.com...
 I'd like to add that from my 6 years with C++, I have never been _saved_ (
 to my knowledge -- knock on wood ) by const.  And I must have typed it
 thousands of times .

 Not that Im voting against immutability, only that if it does get added 
 its
 as non-intrusive as possible.  But I really don't want to start another
 debate!

Well it is different point of view and it is perfectly valid. For you and for me. The thing is simple: const is a declartion - meta information if you wish. const is more collaborative tool than probably anything else. It is seems like for Walter too - const worth nothing because he is working on his own codebase and he knows *his own* code very well. But we have completely different story in team projects. See, partner developers from China will send us class: class Record { Field[] fields(); } Do you have any idea of how you can use this fields? Can you change fieldset or not? Again, for a lone-code-wolf writing 50000 lines code in three months const is (probably) just nothing if not worse - more chars to type. For the team it is a way to reduce needed documentation for example - quite opposite to your situation. C++ and C99 has "char[]" and "const char[]" which are two distinct types. D has only one char[]. Step back? Yes. Again, it seems that having readonly array type (like char#[] ) will allow to reduce problem significantly. For classes and objects you can create readonly envelopes, but arrays are naked in this regard. You can create as many meta programming features as you wish but without such basic feature your type system is just Andrew.

Feb 09 2006
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Wed, 8 Feb 2006 13:10:19 -0800, Walter Bright wrote:

 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, less 
 we get stuck with a poor design like C++'s.

This is an encouraging response, Walter. Previously I was under the distinct impression that the whole idea of having the D language help coders deal with concept of immutable data was against your philosophy. This note of yours seems to be saying that you can see it happening in D, but only after the right amount of thinking about 'how to do it well' has occurred. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 10/02/2006 10:09:47 AM
Feb 09 2006
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:
 
 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, less 
 we get stuck with a poor design like C++'s. 
 
 

Can someone tell more about what's wrong and/or what could be better with C++'s design(const)? -- Bruno Medeiros - CS/E student "Certain aspects of D are a pathway to many abilities some consider to be... unnatural."
Feb 10 2006
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <dsil1d$1gs8$1 digitaldaemon.com>, Bruno Medeiros says...
Walter Bright wrote:
 
 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, less 
 we get stuck with a poor design like C++'s. 
 
 

Can someone tell more about what's wrong and/or what could be better with C++'s design(const)?

The issue is quite subjective. It depends on what you consider 'wrong'. IMHO, const appears to be the way most of to many developers because that's what its for. By its very nature, it is purposefully designed to make your life harder all in the name of data integrity. Now how it accomplishes that job and wether or not its doing it well is totally up to debate. Personally, I find API authors abusing 'const' nearly as much as API users abusing 'const_cast' so its kind of a toss-up. --------------- As for D: if there was some way to impose the COW idiom on assigning from const to non-const, then I think we'd have a superior solution. At a minimum this would require const to only apply to primitive/scalar types which seems acceptable: classes and structs at least have a way to protect their internals via methods. 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;
   }
 }

- Eric Anderton at yahoo
Feb 10 2006
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 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? Andrew.
Feb 11 2006
parent reply pragma <pragma_member pathlink.com> writes:
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.** 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. * 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. ** 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. - Eric Anderton at yahoo
Feb 11 2006
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"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.
Feb 11 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dsil1d$1gs8$1 digitaldaemon.com...
 Walter Bright wrote:
 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, 
 less we get stuck with a poor design like C++'s.

C++'s design(const)?

"const" has many possible meanings: 1) is the data immutable and set at compile time, so it could be put in ROM? 2) is the pointer itself const, or is the data it points to const? 3) does const mean write-once, i.e. can it be initialized at runtime? 4) can other references to the same data change it? 5) can "constness" be cast away? 6) if one has a "const" array of objects, is the array reference const, the array contents const, or are the object contents const? What about what those objects refer to? 7) what about "logical" constness, where data can appear to be constant but has, in actuallity, "mutable" state? (see C++ "mutable" keyword) And, of course, every combination of the above.
Feb 10 2006
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dsjq1j$5rv$2 digitaldaemon.com...
 "Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
 news:dsil1d$1gs8$1 digitaldaemon.com...
 Walter Bright wrote:
 The problem with some sort of immutable data type is there are at least 
 a dozen different ways to do it. A lot more thinking has to go into 
 this, less we get stuck with a poor design like C++'s.

C++'s design(const)?

"const" has many possible meanings: 1) is the data immutable and set at compile time, so it could be put in ROM? 2) is the pointer itself const, or is the data it points to const?

In C/C++ declaration of const pointer is like this: const typename * -or- typename const * this is just bad - two tokens used in arbitrary order (who invented this?) for declaration of const-ptr. Proposed schema of readonly pointers uses single token '#*' type #* p;
 3) does const mean write-once, i.e. can it be initialized at runtime?

void foo( bar #* p ) means that in scope of function foo '*p' cannot be an l-value.
 4) can other references to the same data change it?

yes.
 5) can "constness" be cast away?

yes. cast is a brute force and last resort but usable. Even Prof. Niklaus Wirth agree with this.
 6) if one has a "const" array of objects, is the array reference const, 
 the array contents const, or are the object contents const? What about 
 what those objects refer to?

bar #[] ar; means that type 'bar #[]' has no operations changing content of the array's raw data (in range ptr...ptr+length ) and pseudo fields ptr and length cannot be changed. Implication: its pseudo variable ptr is type of bar #*
 7) what about "logical" constness, where data can appear to be constant 
 but has, in actuallity, "mutable" state? (see C++ "mutable" keyword)

This is not applicable in D. All objects (instances of some class) are mutable by definition.
 And, of course, every combination of the above.

Well, not too much left. The only problem I see is what to do with structures: struct myst { int a; void m(int b) { a = b; } } myst# *pms = ...; myst ms = ...; I think this would be enough: pms.a = 1; // compile time error - attempt to modify data at location pointed by readonly pointer. - but - pms.m(2); // is fine - author of the type provided explicit mutator. ms = *pms; // is fine - creation of local copy of the variable with // possible modification of that copy. Andrew Fedoniouk. http://terrainformatica.com
Feb 10 2006
prev sibling parent "Kris" <fu bar.com> writes:
"Matthias Spycher" <matthias coware.com> wrote...
 http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

 Does anyone else (Kris?) feel an urgent need for some immutable basic data 
 types in D? Especially in light of the recent plan to translate SWT -> DWT 
 and possible other Java projects in the future. IMHO D should at least 
 provide immutable strings. I'm sure we all agree -- it has been discussed 
 before -- that having some light-weight immutable data types is a good 
 thing in the context of scalable, multi-threaded, GC-enabled programs. Now 
 it just seems more urgent...

Mango has a number of immutable and pseudo-immutable classes (you can still bork the latter type given the lack of compiler support). It turns out that they're not actually needed for SWT ~ not even mango.text.String. While I agree that support for immutability should probably be a pre-requisite for a language that claims to support concurrency, Walter clearly feels it's pretty low on the priority list. We can but hope it will arrive in due time <g>
 Kris, I imagine your translator will be dependent not on just the D 
 language, but also a library, right? If so, which one?

Mango!
Feb 08 2006