www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Round II, Re: Immutable arrays for Walter and rest of us.

reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da2v7t$b9b$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da024r$65o$1 digitaldaemon.com...
 I would like to discuss one of my previous ideas again
 as it seems it was lost in the fire.
I've been discussing this issue with Andrei (of Modern C++ Design fame). He points out that there are numerous different "const" semantics, each having their uses and disadvantages. He suggests that all should be supported in one way or another, and I agree that that would have some advantages. One of my (several) dislikes with "const" is that most (90% ?) of a function's parameters are likely to be "const". So one winds up with the C++ aesthetically ugly consequence of "const" here, there, everywhere. And you can't use it casually here and there, once you start down the road of making a few functions have "const" parameters, you've got to do it throughout the program. So perhaps one could turn that inside out, and make "const" the default for function parameters. If the parameter was to be changed, it'd be explicitly marked as "mutable" or some such. But that runs into another problem. Function local variables, on the other hand, one would want to be "mutable" by default. There's also the issue that "const" already exists as a variable storage class. So far, I haven't thought of anything that makes consistent sense, and doesn't look like an ugly hack. One thing I have thought of is a compromise. Change the semantics of explicitly "in" parameters to be what Andrei calls "deep immutable". Deep immutable parameters would have unchanging values for the scope of that parameter, and also every sub-object reachable by that parameter would also be unchangeable. The values wouldn't change even by another reference or another thread. (This is quite unlike C++ "const".) "in" would be a promise by the programmer, and could not be guaranteed by the compiler - but - the optimizer can take advantage of this promise to generate perhaps significantly better code. (With C++ "const", values can change at any momen t by another reference or another thread, making optimizations based on "const" impossible.) C++ "const" is enforced by the compiler, but is useless semantic information. "in" is not enforced by the compiler beyond the trivial, but is useful semantic information.
I think that "deep immutables" ((C) Andrei Alexandrescu, I guess) are ideal but too deep to be considered as a solution for practical (read fast) compiler. L-value analysis in this case might be a) cyclic (not sure but highly suspect this) and b) too complex - depth of trees. ----------------------------- I would like to emphasize my proposal again: First of all: D already has mechanism to force (to implement) deep immutability. class Immutable { public int prop() { ... } [private] int prop(int v) { assert(false); } SomeObject propO() { return ([this is immutable])? new Immutable(): new Mutable(); } } As you can see mutating properties/methods can be disabled at compile time ( private accessor ) and/or at runtime ( assert-throw ) Main logical/design conflict is: there is no such (available to developer) mechanism for arrays and pointers. They are 'naked' - always mutable. Main idea of my proposal is in defining new array and pointer types: immutable array and immutable pointer. Let's say that D array type internally declared as primitive "[ ]" (T) { private T *_ptr; private uint _length; T * ptr() { return _ptr; } private void ptr(T *) { } // ptr is not an L-value. uint length() { return _length; } uint length(uint nl) { resize(); return _length; } void opIndexAssign(int index, T v) { _ptr[ index ] = v; } void opAssign(struct "[ ]" (T) r) { _ptr = r._ptr; _length = r._length; } } { private uint _length; uint length() { return _length; } private uint length(uint nl) { resize(); return _length; } // no such op available private void opIndexAssign(int index, T v); // no such op available private void opAssign(struct "[ ]" (T) r); // no such op available // but this one is here - immutable <- immutable : r._length; } } Having it you'll close the only one "immutability hole" left in D. Again, structs and classes already have a protection layer availbale - you can always create a protecting perimeter for your classes/structs: public property-methods and just methods of any needed depth. You can return from functions mutable or immutable struct and class instances using various policies. perfect) - *all* D types will have an option to be immutable. Andrew.
Jul 01 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 One thing I have thought of is a compromise. Change the semantics of
 explicitly "in" parameters to be what Andrei calls "deep immutable". Deep
 immutable parameters would have unchanging values for the scope of that
 parameter, and also every sub-object reachable by that parameter would 
 also
 be unchangeable. The values wouldn't change even by another reference or
 another thread. (This is quite unlike C++ "const".) "in" would be a 
 promise
 by the programmer, and could not be guaranteed by the compiler - but - 
 the
 optimizer can take advantage of this promise to generate perhaps
 significantly better code. (With C++ "const", values can change at any 
 momen
 t by another reference or another thread, making optimizations based on
 "const" impossible.)

 C++ "const" is enforced by the compiler, but is useless semantic
 information. "in" is not enforced by the compiler beyond the trivial, but 
 is
 useful semantic information.
I think that "deep immutables" ((C) Andrei Alexandrescu, I guess) are ideal but too deep to be considered as a solution for practical (read fast) compiler. L-value analysis in this case might be a) cyclic (not sure but highly suspect this) and b) too complex - depth of trees. ----------------------------- I would like to emphasize my proposal again: First of all: D already has mechanism to force (to implement) deep immutability. class Immutable { public int prop() { ... } [private] int prop(int v) { assert(false); } SomeObject propO() { return ([this is immutable])? new Immutable(): new Mutable(); } } As you can see mutating properties/methods can be disabled at compile time ( private accessor ) and/or at runtime ( assert-throw )
How would this cover the following case that Walter's proposal covers: class A { int x; } void foo(in A obj){ int y = obj.x; // do whatever you want... assert( obj.x == y ); } void main() { A obj = new A; foo(obj); // says it doesn't change obj } Is it practical to force A to implement some immutability just because foo doesn't change its inputs? I'm not saying Walter's proposal is prefect. It's very strong for foo to say no other thread or reference will change obj since it has no control over what other threads are doing. I would be taking pretty much blind leap of faith when declaring an object reference as 'in' and saying that no other thread is stepping on that object during the call lifetime.
 Main logical/design conflict is: there is no such (available to developer)
 mechanism for arrays and pointers. They are 'naked' - always mutable.

 Main idea of my proposal is in defining new array and pointer types:

 immutable array and immutable pointer.






 Let's say that D array type internally declared as
[snip]

The complexity of the implementation is one thing - another is the impact of introducing a new array type (and pointer type) on existing and future user code.
 Having it you'll close the only one "immutability hole" left in D.

 Again, structs and classes already have a protection layer availbale -
 you can always create a protecting perimeter for your classes/structs:
 public property-methods and just methods of any needed depth.
 You can return from functions mutable or immutable struct and class 
 instances
 using various policies.


 perfect) -
 *all* D types will have an option to be immutable.

 Andrew.
Jul 01 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:da4afr$24jc$1 digitaldaemon.com...
 One thing I have thought of is a compromise. Change the semantics of
 explicitly "in" parameters to be what Andrei calls "deep immutable". 
 Deep
 immutable parameters would have unchanging values for the scope of that
 parameter, and also every sub-object reachable by that parameter would 
 also
 be unchangeable. The values wouldn't change even by another reference or
 another thread. (This is quite unlike C++ "const".) "in" would be a 
 promise
 by the programmer, and could not be guaranteed by the compiler - but - 
 the
 optimizer can take advantage of this promise to generate perhaps
 significantly better code. (With C++ "const", values can change at any 
 momen
 t by another reference or another thread, making optimizations based on
 "const" impossible.)

 C++ "const" is enforced by the compiler, but is useless semantic
 information. "in" is not enforced by the compiler beyond the trivial, 
 but is
 useful semantic information.
I think that "deep immutables" ((C) Andrei Alexandrescu, I guess) are ideal but too deep to be considered as a solution for practical (read fast) compiler. L-value analysis in this case might be a) cyclic (not sure but highly suspect this) and b) too complex - depth of trees. ----------------------------- I would like to emphasize my proposal again: First of all: D already has mechanism to force (to implement) deep immutability. class Immutable { public int prop() { ... } [private] int prop(int v) { assert(false); } SomeObject propO() { return ([this is immutable])? new Immutable(): new Mutable(); } } As you can see mutating properties/methods can be disabled at compile time ( private accessor ) and/or at runtime ( assert-throw )
How would this cover the following case that Walter's proposal covers: class A { int x; } void foo(in A obj){ int y = obj.x; // do whatever you want... assert( obj.x == y ); } void main() { A obj = new A; foo(obj); // says it doesn't change obj } Is it practical to force A to implement some immutability just because foo doesn't change its inputs? I'm not saying Walter's proposal is prefect. It's very strong for foo to say no other thread or reference will change obj since it has no control over what other threads are doing. I would be taking pretty much blind leap of faith when declaring an object reference as 'in' and saying that no other thread is stepping on that object during the call lifetime.
in/inout/out describes mechanism of passing parameters - by ref or by value. foo( in char[] str ) means that value of str will not be changed after return from function. But it does not disallow you to change the value of str is pointing to. This makes perfect sense for me. and as by definition of immutable array content pointed by str.ptr will not be changed. all have usable sense as do foo( in char[] str ) foo( inout char[] str ) foo( out char[] str ) Please don't change this. in is not a const in any sense. 'in' does not allow you to have immutable arrays as properties - and this is imho most valueable thing. allow you and compiler to distinguish cases: foo( char[] str ) thus to build more optimal code structure. With just 'in' it is impossible. Remeber duscussed problem with stream.scanf parameters?
 Main logical/design conflict is: there is no such (available to 
 developer)
 mechanism for arrays and pointers. They are 'naked' - always mutable.

 Main idea of my proposal is in defining new array and pointer types:

 immutable array and immutable pointer.






Pretty much as '+ =' and '+='
 Let's say that D array type internally declared as
[snip]

 simple.
The complexity of the implementation is one thing - another is the impact of introducing a new array type (and pointer type) on existing and future user code.
Existing code will not be impacted heavily. It depends of what static array will be. significantly simplify life and make D clear. Now it is just sequence of "why's" - why it allowed here and not there. First step - to make it compileable is 15 minutes - exactly the same amount of time it took me to replace all inner classes with static inner classes.
 Having it you'll close the only one "immutability hole" left in D.

 Again, structs and classes already have a protection layer availbale -
 you can always create a protecting perimeter for your classes/structs:
 public property-methods and just methods of any needed depth.
 You can return from functions mutable or immutable struct and class 
 instances
 using various policies.


 (almost perfect) -
 *all* D types will have an option to be immutable.

 Andrew.
Jul 01 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message
news:da4afr$24jc$1 digitaldaemon.com...
 How would this cover the following case that Walter's proposal covers:
 class A { int x; }
 void foo(in A obj){
   int y = obj.x;
   // do whatever you want...
   assert( obj.x == y );
 }
 void main() {
   A obj = new A;
   foo(obj); // says it doesn't change obj
 }
 Is it practical to force A to implement some immutability just because foo
 doesn't change its inputs? I'm not saying Walter's proposal is prefect.
It's
 very strong for foo to say no other thread or reference will change obj
 since it has no control over what other threads are doing. I would be
taking
 pretty much blind leap of faith when declaring an object reference as 'in'
 and saying that no other thread is stepping on that object during the call
 lifetime.
You're right. I have misgivings about it for that reason. On the other hand, look at C++ "const". Nothing about "const" says that some other thread or reference cannot change the value out from under you at any moment. Furthermore, it can be cast away and modified anyway. The semantic value of C++ "const" is essentially zip. This is why I am often flummoxed why it is given such weight in C++.
Jul 02 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da6k71$11rs$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:da4afr$24jc$1 digitaldaemon.com...
 How would this cover the following case that Walter's proposal covers:
 class A { int x; }
 void foo(in A obj){
   int y = obj.x;
   // do whatever you want...
   assert( obj.x == y );
 }
 void main() {
   A obj = new A;
   foo(obj); // says it doesn't change obj
 }
 Is it practical to force A to implement some immutability just because 
 foo
 doesn't change its inputs? I'm not saying Walter's proposal is prefect.
It's
 very strong for foo to say no other thread or reference will change obj
 since it has no control over what other threads are doing. I would be
taking
 pretty much blind leap of faith when declaring an object reference as 
 'in'
 and saying that no other thread is stepping on that object during the 
 call
 lifetime.
You're right. I have misgivings about it for that reason. On the other hand, look at C++ "const". Nothing about "const" says that some other thread or reference cannot change the value out from under you at any moment. Furthermore, it can be cast away and modified anyway. The semantic value of C++ "const" is essentially zip. This is why I am often flummoxed why it is given such weight in C++.
Personally I'm also surprised people are so paranoid in D about possible COW violations. What's the phrase from Spiderman ... "with great power comes great responsibility" :-) Granted in Java people IMO overcompensate by dup'ing too often so I hope D users don't go that route.
Jul 02 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:da7fo5$bje$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message 
 news:da6k71$11rs$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:da4afr$24jc$1 digitaldaemon.com...
 How would this cover the following case that Walter's proposal covers:
 class A { int x; }
 void foo(in A obj){
   int y = obj.x;
   // do whatever you want...
   assert( obj.x == y );
 }
 void main() {
   A obj = new A;
   foo(obj); // says it doesn't change obj
 }
 Is it practical to force A to implement some immutability just because 
 foo
 doesn't change its inputs? I'm not saying Walter's proposal is prefect.
It's
 very strong for foo to say no other thread or reference will change obj
 since it has no control over what other threads are doing. I would be
taking
 pretty much blind leap of faith when declaring an object reference as 
 'in'
 and saying that no other thread is stepping on that object during the 
 call
 lifetime.
You're right. I have misgivings about it for that reason. On the other hand, look at C++ "const". Nothing about "const" says that some other thread or reference cannot change the value out from under you at any moment. Furthermore, it can be cast away and modified anyway. The semantic value of C++ "const" is essentially zip. This is why I am often flummoxed why it is given such weight in C++.
Personally I'm also surprised people are so paranoid in D about possible COW violations. What's the phrase from Spiderman ... "with great power comes great responsibility" :-) Granted in Java people IMO overcompensate by dup'ing too often so I hope D users don't go that route.
Umm... Java has 'final' keyword. You define an entity once and cannot change it or derive from it later. More specifically: a final class cannot be subclassed, a final method cannot be overridden and a final variable cannot change from its initialized value. Function parameters can also be declared as final. in declaration of function parameters. is protecting also references. E.g. you cannot say "hello"[0] = 'b'; And more regarding strings in these systems: Java/.NET String "package" consist of 1) String class (immutable) and 2) StringBuffer (mutable) class Literal strings there are instances of String class which is immutable, sic! I would like to highlight this again: In modern programming systems string implementation is a bundle of friendly value classes (immutable) and buffer (mutable) classes. D currently has only StringBuffer (sort of).
Jul 02 2005
next sibling parent reply Stefan Zobel <Stefan_member pathlink.com> writes:
In article <da7i52$cv9$1 digitaldaemon.com>, Andrew Fedoniouk says...
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:da7fo5$bje$1 digitaldaemon.com...



Umm...

Java has 'final' keyword. You define an entity once and cannot change it or 
derive from it later. More specifically: a final class cannot be subclassed, 
a final method cannot be overridden and a final variable cannot change from 
its initialized value. Function parameters can also be declared as final.


in declaration of function parameters.

is protecting also references. E.g. you cannot
say "hello"[0] = 'b';

And more regarding strings in these systems:

Java/.NET String "package" consist of

1) String class (immutable) and
2) StringBuffer (mutable) class

Literal strings there are instances of String class
which is immutable, sic!

I would like to highlight this again:

In modern programming systems string implementation is a bundle
of friendly value classes (immutable) and buffer (mutable) classes.

D currently has only StringBuffer (sort of).



Hi Andrew, hhm, I agree with most of your points here. You once said in this discussion that it is impossible to implement something like Java String in D. Apart from D string literals (char[]), I fail to see why. Could you please explain? Kind regards, Stefan (Of course, I think, we all agree that unnecessary dup'ing is undesirable, but that doesn't render it "impossible").
Jul 02 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Stefan Zobel" <Stefan_member pathlink.com> wrote in message 
news:da7jlk$dtk$1 digitaldaemon.com...
 In article <da7i52$cv9$1 digitaldaemon.com>, Andrew Fedoniouk says...
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:da7fo5$bje$1 digitaldaemon.com...



Umm...

Java has 'final' keyword. You define an entity once and cannot change it 
or
derive from it later. More specifically: a final class cannot be 
subclassed,
a final method cannot be overridden and a final variable cannot change 
from
its initialized value. Function parameters can also be declared as final.


and
in declaration of function parameters.


is protecting also references. E.g. you cannot
say "hello"[0] = 'b';

And more regarding strings in these systems:

Java/.NET String "package" consist of

1) String class (immutable) and
2) StringBuffer (mutable) class

Literal strings there are instances of String class
which is immutable, sic!

I would like to highlight this again:

In modern programming systems string implementation is a bundle
of friendly value classes (immutable) and buffer (mutable) classes.

D currently has only StringBuffer (sort of).



Hi Andrew, hhm, I agree with most of your points here. You once said in this discussion that it is impossible to implement something like Java String in D. Apart from D string literals (char[]), I fail to see why. Could you please explain? Kind regards, Stefan (Of course, I think, we all agree that unnecessary dup'ing is undesirable, but that doesn't render it "impossible").
(Sorry, missed your message initially) Strictly speaking it is possible to define String in D with exact set of methods and behavior as Java string. Mea culpa - I was not exact in terms. I mean it is almost impossible to use such String effectively. System and OS functions demands char* which you cannot get from String by its specification. Powerfull mechanism of slices is also lost here. Yes, as you mentioned, you can dup on each opSlice call but this is not a practical option. Again beg my pardon. Andrew.
Jul 04 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:da7i52$cv9$1 digitaldaemon.com...
 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
 news:da7fo5$bje$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message 
 news:da6k71$11rs$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:da4afr$24jc$1 digitaldaemon.com...
 How would this cover the following case that Walter's proposal covers:
 class A { int x; }
 void foo(in A obj){
   int y = obj.x;
   // do whatever you want...
   assert( obj.x == y );
 }
 void main() {
   A obj = new A;
   foo(obj); // says it doesn't change obj
 }
 Is it practical to force A to implement some immutability just because 
 foo
 doesn't change its inputs? I'm not saying Walter's proposal is prefect.
It's
 very strong for foo to say no other thread or reference will change obj
 since it has no control over what other threads are doing. I would be
taking
 pretty much blind leap of faith when declaring an object reference as 
 'in'
 and saying that no other thread is stepping on that object during the 
 call
 lifetime.
You're right. I have misgivings about it for that reason. On the other hand, look at C++ "const". Nothing about "const" says that some other thread or reference cannot change the value out from under you at any moment. Furthermore, it can be cast away and modified anyway. The semantic value of C++ "const" is essentially zip. This is why I am often flummoxed why it is given such weight in C++.
Personally I'm also surprised people are so paranoid in D about possible COW violations. What's the phrase from Spiderman ... "with great power comes great responsibility" :-) Granted in Java people IMO overcompensate by dup'ing too often so I hope D users don't go that route.
Umm... Java has 'final' keyword. You define an entity once and cannot change it or derive from it later. More specifically: a final class cannot be subclassed, a final method cannot be overridden and a final variable cannot change from its initialized value. Function parameters can also be declared as final.
Currently D's final is more limited than Java's but I have always assumed D's final will eventually match Java's. It still isn't the same as C++'s const, though.

 and in declaration of function parameters.


 say "hello"[0] = 'b';
Sure, but this, too, isn't const. D has getters and setters so one can make you mean by "is protecting also references". The example you give is of a as far as I know. How does one make a non-string reference const?
 And more regarding strings in these systems:

 Java/.NET String "package" consist of

 1) String class (immutable) and
 2) StringBuffer (mutable) class

 Literal strings there are instances of String class
 which is immutable, sic!
It's also probably the most common use of const in C++. To me that isn't enough reason to introduce const, though.
 I would like to highlight this again:

 In modern programming systems string implementation is a bundle
 of friendly value classes (immutable) and buffer (mutable) classes.

 D currently has only StringBuffer (sort of).



Why bother with multiple types/classes when D already spanks the competition with one? We should keep things as simple as possible.
Jul 02 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:da7mmr$fjl$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:da7i52$cv9$1 digitaldaemon.com...
 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
 news:da7fo5$bje$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message 
 news:da6k71$11rs$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:da4afr$24jc$1 digitaldaemon.com...
 How would this cover the following case that Walter's proposal covers:
 class A { int x; }
 void foo(in A obj){
   int y = obj.x;
   // do whatever you want...
   assert( obj.x == y );
 }
 void main() {
   A obj = new A;
   foo(obj); // says it doesn't change obj
 }
 Is it practical to force A to implement some immutability just because 
 foo
 doesn't change its inputs? I'm not saying Walter's proposal is 
 prefect.
It's
 very strong for foo to say no other thread or reference will change 
 obj
 since it has no control over what other threads are doing. I would be
taking
 pretty much blind leap of faith when declaring an object reference as 
 'in'
 and saying that no other thread is stepping on that object during the 
 call
 lifetime.
You're right. I have misgivings about it for that reason. On the other hand, look at C++ "const". Nothing about "const" says that some other thread or reference cannot change the value out from under you at any moment. Furthermore, it can be cast away and modified anyway. The semantic value of C++ "const" is essentially zip. This is why I am often flummoxed why it is given such weight in C++.
Personally I'm also surprised people are so paranoid in D about possible COW violations. What's the phrase from Spiderman ... "with great power comes great responsibility" :-) Granted in Java people IMO overcompensate by dup'ing too often so I hope D users don't go that route.
Umm... Java has 'final' keyword. You define an entity once and cannot change it or derive from it later. More specifically: a final class cannot be subclassed, a final method cannot be overridden and a final variable cannot change from its initialized value. Function parameters can also be declared as final.
Currently D's final is more limited than Java's but I have always assumed D's final will eventually match Java's. It still isn't the same as C++'s const, though.
Yes, Java::final is not a C::const (it cannot protect references). Java::final is exactly D::const now except of Java::final can be used in function parameters declaration and D's counterpart - cannot. I have no idea of what D::final means. It is defined as a keyword but have no meaning so far, AFAIK. (correct me.)

 and in declaration of function parameters.


 say "hello"[0] = 'b';
Sure, but this, too, isn't const. D has getters and setters so one can what you mean by "is protecting also references". The example you give is keyword as far as I know. How does one make a non-string reference const?
( http://en.wikipedia.org/wiki/Const_correctness ) too. Neither do Java. But they do have immutable strings, you are right higlighting this.
 And more regarding strings in these systems:

 Java/.NET String "package" consist of

 1) String class (immutable) and
 2) StringBuffer (mutable) class

 Literal strings there are instances of String class
 which is immutable, sic!
It's also probably the most common use of const in C++. To me that isn't enough reason to introduce const, though.
std.openrj.d: class Record { Field[] fields() { return m_fields.dup; } } Do you like this dup? class Field { final char[] name() { return m_name; } } Pay attention that std.openrj is an attempt to create OOP, reusable, effective and robust library module in D. Lack of constness is seen in each class of it.
 I would like to highlight this again:

 In modern programming systems string implementation is a bundle
 of friendly value classes (immutable) and buffer (mutable) classes.

 D currently has only StringBuffer (sort of).



Why bother with multiple types/classes when D already spanks the competition with one? We should keep things as simple as possible.
Agreed in principle, but "simple as possible" does not mean "sancta simplicitas", right? "I'll give you my slice and don't forget to dup it as it is not yours." This does not work in serious programming as slice creation happens in one place and its consuming in galaxy far far away and code of three developers happens in between. It is EXTREMELY difficult to debug. I know. It happened to me once in Harmonia and I wasted almost three days to catch it. Sigh... And I was designing it by myself - not even in team... Andrew.
Jul 02 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:da7s6r$jcd$1 digitaldaemon.com...
 "I'll give you my slice and don't forget to dup it as it is not yours."
 This does not work in serious programming as
 slice creation happens in one place and its consuming
 in galaxy far far away and code of three developers
 happens in between. It is EXTREMELY difficult to debug.
 I know. It happened to me once in Harmonia and I wasted
 almost three days to catch it. Sigh...
 And I was designing it by myself - not even in team...
The COW rule for when to .dup is: When you're going to change the data, and you're not *sure* you're the sole handle to it. I don't see why the need is there for m_fields.dup in openrj.d. Preemptively duping something by the provider is the wrong approach to COW. Duping should be done by the consumer of it, and then only if the consumer modifies it.
Jul 02 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da7u7k$kkh$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da7s6r$jcd$1 digitaldaemon.com...
 "I'll give you my slice and don't forget to dup it as it is not yours."
 This does not work in serious programming as
 slice creation happens in one place and its consuming
 in galaxy far far away and code of three developers
 happens in between. It is EXTREMELY difficult to debug.
 I know. It happened to me once in Harmonia and I wasted
 almost three days to catch it. Sigh...
 And I was designing it by myself - not even in team...
The COW rule for when to .dup is: When you're going to change the data, and you're not *sure* you're the sole handle to it.
In real projects and in real life this *not sure* is almost always.
 I don't see why the need is there for m_fields.dup in openrj.d. 
 Preemptively
 duping something by the provider is the wrong approach to COW. Duping 
 should
 be done by the consumer of it, and then only if the consumer modifies it.
I know this theory. The whole team are C++ programmers. They get used to const. And you know.... this is really a "code culture" thing - respect of developers who are working with you and using your code. const - it is mine - don't touch it. no const - it is yours. And C++ compiler helps us a lot here to prevent stupid mistakes. All most respectfull C++ guys are unified in 'const is good'' http://artima.com/intv/const.html Shall I tell my team that const is wrong because: "it is useless for optimizing"? I'll never will do that, sorry. pointers are so effective but dangerous. without const they are dangerous in order of magnitude. The same apply to D slices. Andrew.
Jul 02 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:da818n$md2$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:da7u7k$kkh$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da7s6r$jcd$1 digitaldaemon.com...
 "I'll give you my slice and don't forget to dup it as it is not yours."
 This does not work in serious programming as
 slice creation happens in one place and its consuming
 in galaxy far far away and code of three developers
 happens in between. It is EXTREMELY difficult to debug.
 I know. It happened to me once in Harmonia and I wasted
 almost three days to catch it. Sigh...
 And I was designing it by myself - not even in team...
The COW rule for when to .dup is: When you're going to change the data, and you're not *sure* you're
the
 sole handle to it.
In real projects and in real life this *not sure* is almost always.
True, but it's also true that most of the time, one doesn't care because one has no need to modify the data.
 I don't see why the need is there for m_fields.dup in openrj.d.
 Preemptively
 duping something by the provider is the wrong approach to COW. Duping
 should
 be done by the consumer of it, and then only if the consumer modifies
it.
 I know this theory.

 The whole team are C++ programmers. They get used to const.
 And you know.... this is really a "code culture" thing -
 respect of developers who are working with you and using
 your code.
 const - it is mine - don't touch it. no const - it is yours.
 And C++ compiler helps us a lot here to prevent stupid mistakes.

 All most respectfull C++ guys are unified in 'const is good''
 http://artima.com/intv/const.html
 Shall I tell my team that const is wrong because:
 "it is useless for optimizing"?
 I'll never will do that, sorry.
C++ const benefits are greater than zero, even though it is useless to the optimizer as it gives no meaningful semantic information.
 pointers are so effective but dangerous. without const they are
 dangerous in order of magnitude. The same apply to D slices.
I find it curious that many features of C++ have leaked out into other languages, but not const. I agree with you that C++ has a culture of "const is good". I'd like to find something better, something that works (i.e. that gives useful semantic information). I also am not understanding how const would help with COW mistakes.
Jul 03 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da888e$rhs$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da818n$md2$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:da7u7k$kkh$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da7s6r$jcd$1 digitaldaemon.com...
 "I'll give you my slice and don't forget to dup it as it is not 
 yours."
 This does not work in serious programming as
 slice creation happens in one place and its consuming
 in galaxy far far away and code of three developers
 happens in between. It is EXTREMELY difficult to debug.
 I know. It happened to me once in Harmonia and I wasted
 almost three days to catch it. Sigh...
 And I was designing it by myself - not even in team...
The COW rule for when to .dup is: When you're going to change the data, and you're not *sure* you're
the
 sole handle to it.
In real projects and in real life this *not sure* is almost always.
True, but it's also true that most of the time, one doesn't care because one has no need to modify the data.
Absolutely true. This is why e.g. string literals shall have type const char[] and not just a char[] by default. This is stupid design mistake in C++: "hello"[0] = 0; will compile and run on one machines and will not on others.
 I don't see why the need is there for m_fields.dup in openrj.d.
 Preemptively
 duping something by the provider is the wrong approach to COW. Duping
 should
 be done by the consumer of it, and then only if the consumer modifies
it.
 I know this theory.

 The whole team are C++ programmers. They get used to const.
 And you know.... this is really a "code culture" thing -
 respect of developers who are working with you and using
 your code.
 const - it is mine - don't touch it. no const - it is yours.
 And C++ compiler helps us a lot here to prevent stupid mistakes.

 All most respectfull C++ guys are unified in 'const is good''
 http://artima.com/intv/const.html
 Shall I tell my team that const is wrong because:
 "it is useless for optimizing"?
 I'll never will do that, sorry.
C++ const benefits are greater than zero, even though it is useless to the optimizer as it gives no meaningful semantic information.
 pointers are so effective but dangerous. without const they are
 dangerous in order of magnitude. The same apply to D slices.
I find it curious that many features of C++ have leaked out into other languages, but not const.
Walter, need of const appears together with raw pointers. It is critical to have pointers (slices included) together with const. If some language takes ++ from C but not pointers then it does not need const so much. There is no language in active use which has raw pointers and has no concept of pointers to const data. Even C. It had no const from the very beginning. But C99 (year of 1999, sic) has it. const is simply a type designator: const typename* and typename* *are* different types - with different behavior. Combining them in one entity as you did in D design is exactly the same as having only one int type without unsigned counterpart.
 I agree with you that C++ has a culture of "const is good".

 I'd like to find something better, something that works (i.e. that gives
 useful semantic information).

 I also am not understanding how const would help with COW mistakes.
What are the "COW mistakes"? I don't understand this exactly.... Anyway.... void toLower(in char[] str) char[] toLower(in const char[] str) Having them both is a matter of optimization. First does transformation in place, second allocates new string. Do these two together make sense? Definitely, yes.
Jul 03 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:da97g2$1l30$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:da888e$rhs$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da818n$md2$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:da7u7k$kkh$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da7s6r$jcd$1 digitaldaemon.com...
 "I'll give you my slice and don't forget to dup it as it is not
 yours."
 This does not work in serious programming as
 slice creation happens in one place and its consuming
 in galaxy far far away and code of three developers
 happens in between. It is EXTREMELY difficult to debug.
 I know. It happened to me once in Harmonia and I wasted
 almost three days to catch it. Sigh...
 And I was designing it by myself - not even in team...
The COW rule for when to .dup is: When you're going to change the data, and you're not *sure* you're
the
 sole handle to it.
In real projects and in real life this *not sure* is almost always.
True, but it's also true that most of the time, one doesn't care because one has no need to modify the data.
Absolutely true. This is why e.g. string literals shall have type const char[] and not just a char[] by default. This is stupid design mistake in C++: "hello"[0] = 0; will compile and run on one machines and will not on others.
It is an error in C++ to do that, though it is allowed by some compilers for backwards compatibility. In C++, string literals are const char*.
 Walter, need of const appears together with raw pointers.
 It is critical to have pointers (slices included) together
 with const.

 If some language takes ++ from C but not pointers then
 it does not need const so much.

 There is no language in active use which has raw pointers
 and has no concept of pointers to const data.
I don't know of any language that even allows raw pointers other than C, C++ and D!
 I agree with you that C++ has a culture of "const is good".

 I'd like to find something better, something that works (i.e. that gives
 useful semantic information).

 I also am not understanding how const would help with COW mistakes.
What are the "COW mistakes"? I don't understand this exactly....
A COW mistake would be, for example, modifying a reference when you aren't sure you're the owner of it.
 Anyway....

 void  toLower(in char[] str)
 char[]  toLower(in const char[] str)


 Having them both is a matter of optimization.
 First does transformation in place, second allocates
 new string.

 Do these two together make sense? Definitely, yes.
See my comments on this example in another post here.
Jul 03 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da9dc2$1r5s$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da97g2$1l30$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:da888e$rhs$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da818n$md2$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:da7u7k$kkh$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da7s6r$jcd$1 digitaldaemon.com...
 "I'll give you my slice and don't forget to dup it as it is not
 yours."
 This does not work in serious programming as
 slice creation happens in one place and its consuming
 in galaxy far far away and code of three developers
 happens in between. It is EXTREMELY difficult to debug.
 I know. It happened to me once in Harmonia and I wasted
 almost three days to catch it. Sigh...
 And I was designing it by myself - not even in team...
The COW rule for when to .dup is: When you're going to change the data, and you're not *sure* you're
the
 sole handle to it.
In real projects and in real life this *not sure* is almost always.
True, but it's also true that most of the time, one doesn't care because one has no need to modify the data.
Absolutely true. This is why e.g. string literals shall have type const char[] and not just a char[] by default. This is stupid design mistake in C++: "hello"[0] = 0; will compile and run on one machines and will not on others.
It is an error in C++ to do that, though it is allowed by some compilers for backwards compatibility. In C++, string literals are const char*.
 Walter, need of const appears together with raw pointers.
 It is critical to have pointers (slices included) together
 with const.

 If some language takes ++ from C but not pointers then
 it does not need const so much.

 There is no language in active use which has raw pointers
 and has no concept of pointers to const data.
I don't know of any language that even allows raw pointers other than C, C++ and D!
Delphi: function CopyStr(const aSourceString : string; aStart, aLength : Integer) : string;
 I agree with you that C++ has a culture of "const is good".

 I'd like to find something better, something that works (i.e. that 
 gives
 useful semantic information).

 I also am not understanding how const would help with COW mistakes.
What are the "COW mistakes"? I don't understand this exactly....
A COW mistake would be, for example, modifying a reference when you aren't sure you're the owner of it.
See, I even don't know about these errors as I am using void foo(const char[] s) { s[0] = 0; // here compiler rises an error - warnig me.... } Is it bad?
 Anyway....

 void  toLower(in char[] str)
 char[]  toLower(in const char[] str)


 Having them both is a matter of optimization.
 First does transformation in place, second allocates
 new string.

 Do these two together make sense? Definitely, yes.
See my comments on this example in another post here.
Jul 03 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da6k71$11rs$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:da4afr$24jc$1 digitaldaemon.com...
 How would this cover the following case that Walter's proposal covers:
 class A { int x; }
 void foo(in A obj){
   int y = obj.x;
   // do whatever you want...
   assert( obj.x == y );
 }
 void main() {
   A obj = new A;
   foo(obj); // says it doesn't change obj
 }
 Is it practical to force A to implement some immutability just because 
 foo
 doesn't change its inputs? I'm not saying Walter's proposal is prefect.
It's
 very strong for foo to say no other thread or reference will change obj
 since it has no control over what other threads are doing. I would be
taking
 pretty much blind leap of faith when declaring an object reference as 
 'in'
 and saying that no other thread is stepping on that object during the 
 call
 lifetime.
You're right. I have misgivings about it for that reason. On the other hand, look at C++ "const". Nothing about "const" says that some other thread or reference cannot change the value out from under you at any moment. Furthermore, it can be cast away and modified anyway. The semantic value of C++ "const" is essentially zip. This is why I am often flummoxed why it is given such weight in C++.
"This is why I am often flummoxed why it is given such weight in C++." Walter, consider 'const' as just any other access specifier: private, public, protected, etc. "const" has pretty much the same usability weight as these. const is not a physical protection. And never was. It is logical declaration of intention: I am not going to change this parameter or value it is refereing, so, compiler, please, warn me if I'll do this accidentally.
Jul 02 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
One more:


has concept of const (parameters and references)
and these are the most popular languages so far.
Jul 02 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:da7jil$dsm$1 digitaldaemon.com...
 One more:


 has concept of const (parameters and references)
 and these are the most popular languages so far.
Java only has top level const (final). Any data referred to by a final reference can be changed through that reference (or any other reference to the same object). About the only value it has other than simple constant folding (as pointed out by Matthew) is that any uninitialized finals must be initialized exactly once in the constructors. As far as preventing a function from modifying the fields of a 'final' reference parameter, it is useless.
Jul 02 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da7t1t$jth$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da7jil$dsm$1 digitaldaemon.com...
 One more:


 has concept of const (parameters and references)
 and these are the most popular languages so far.
Java only has top level const (final). Any data referred to by a final reference can be changed through that reference (or any other reference to the same object). About the only value it has other than simple constant folding (as pointed out by Matthew) is that any uninitialized finals must be initialized exactly once in the constructors. As far as preventing a function from modifying the fields of a 'final' reference parameter, it is useless.
Working horses C, C++, Delphi still there though.
Jul 02 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:da7j26$dkb$1 digitaldaemon.com...
 const is not a physical protection. And never was.
 It is logical declaration of intention:

      I am not going to change this parameter or
      value it is refereing, so, compiler, please,
      warn me if I'll do this accidentally.
Yet the value can change anyway. Another reference can change it, and another thread can change it. It isn't "constant" at all, and cannot be relied on to be constant, even if your program is 100% "const-correct". The C++ const is *completely useless* to the compiler optimizer for that reason. A const thing that instead, is a guarantee that the underlying values won't change, is actually useful. An optimizer can do a lot with it.
Jul 02 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da7pp5$i06$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da7j26$dkb$1 digitaldaemon.com...
 const is not a physical protection. And never was.
 It is logical declaration of intention:

      I am not going to change this parameter or
      value it is refereing, so, compiler, please,
      warn me if I'll do this accidentally.
Yet the value can change anyway. Another reference can change it, and another thread can change it. It isn't "constant" at all, and cannot be relied on to be constant, even if your program is 100% "const-correct". The C++ const is *completely useless* to the compiler optimizer for that reason.
Right! Let's throw out private, protected, etc. As they are: (here goes citation of your statement above) Who the hell started this 'canard' (hoax, fr.) that const is for compiler optimization? const is a basic of DbC. It is a contrct. Not more not less. const references allows to mininimize needless memory allocations in design. This is true. And this is how 'const' helps optimization. Best optimizer is you and me - not a compiler. Table at bottom of http://www.terrainformatica.com/htmlayout/ It is not about const but const was a significant part of it.
 A const thing that instead, is a guarantee that the underlying values 
 won't
 change, is actually useful. An optimizer can do a lot with it.
ooohh... could you first provide me an option to *declare* e.g. slice as immutable thus I'll be able to return it from function without duping it? *That* would be optimization. Walter, again, what language are you going to substitute by D? What is the main target? C/C++? If yes then they have const references. and very desireable with slices - they are extremely useful and are making D so attractive (among other good and useful features). Again, in my opinion 1) const references - const arrays and pointers 2) opAssign/dtors in structures are the *only* things left in D not-implemented from C++ feature set. If they will be there you and anyone can honestly say "D is next letter after C and C++" as it allows you to do *everything* that you can in C++ and it has much more "well done" features - true next step. Andrew.
Jul 02 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:da7ulp$kub$1 digitaldaemon.com...
 ooohh... could you first provide me an option to *declare*
 e.g. slice as immutable thus I'll be able to return it from
 function without duping it? *That* would be optimization.
In following COW principles, you do not need to dup the slice when returning it. The producer of the value doesn't need to dup it, the *consumer* does, and only if the *consumer* modifies it. Taking a slice of an array does not modify it in any way, so no dup is required. So I am not understanding why const or immutable is needed for D strings. I've written a number of string processing programs in D (including a macro text processor, and the silly program that transforms newsgroup postings into the "archive" pages), and didn't have any difficulty with D strings. They went together with much less effort and far fewer bugs than their C++ counterparts.
 Walter, again, what language are you going to substitute
 by D? What is the main target? C/C++?
 If yes then they have const references.

 and very desireable with slices - they are extremely useful
 and are making D so attractive (among other good and
 useful features).

 Again, in my opinion
 1) const references - const arrays and pointers
 2) opAssign/dtors in structures
 are the *only* things left in D not-implemented from
 C++ feature set. If they will be there you and anyone
 can honestly say "D is next letter after C and C++" as
 it allows you to do *everything* that you can in C++
 and it has much more "well done" features - true next step.
Unfortunately, there are several other "must haves" various people want D to have. I do understand the desire for const. But there are many different ways to approach the problem, and I'm not willing to just duplicate the C++ const with all its weaknesses and problems. There's got to be a better way.
Jul 03 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Walter wrote:

 So I am not understanding why const or immutable is needed for D strings.
 I've written a number of string processing programs in D (including a macro
 text processor, and the silly program that transforms newsgroup postings
 into the "archive" pages), and didn't have any difficulty with D strings.
 They went together with much less effort and far fewer bugs than their C++
 counterparts.
No offense, but didn't you design the language and string handling ? :-) I've written several segfaults by changing "readonly" literals, and gotten some strange results by setting hash string keys without duping them first (and then later changing the value of the string, that is...) I also think it's pretty easy to "mess up" when using any array slices. It would be great if there were some "extra mechanism" enforcing CoW.
 I do understand the desire for const. But there are many different ways to
 approach the problem, and I'm not willing to just duplicate the C++ const
 with all its weaknesses and problems. There's got to be a better way.
It would nice to come up with an approach that would: a) default local strings/arrays to read-write b) default external parameters to read-only "in"/"out" doesn't really work, since it only affects the array pointer/length and not the actually characters. Maybe something like "char[out] string", but that looks a little like a variable... Anyway, I wouldn't want to see "const" (or "readonly", "immutable") all over the place either - better to have a "readwrite" or "mutable" keyword for the (few?) cases when you *do* want to modify the contents ? I guess it's the D Gentlemen's Agreement, while keeping on searching. (it's easy enough* to implement java.lang.String and StringBuffer in D, but I'm still hoping there is some compromise between "C" and "Java") --anders * PS. Here's one such hack (mostly for the discussion really) http://www.algonet.se/~afb/d/dcaf/html/class_string.html http://www.algonet.se/~afb/d/dcaf/html/class_string_buffer.html
Jul 03 2005
next sibling parent reply Stefan Zobel <Stefan_member pathlink.com> writes:
In article <da8but$t3j$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
I guess it's the D Gentlemen's Agreement, while keeping on searching.
(it's easy enough* to implement java.lang.String and StringBuffer in D,
but I'm still hoping there is some compromise between "C" and "Java")

--anders

* PS. Here's one such hack (mostly for the discussion really)
http://www.algonet.se/~afb/d/dcaf/html/class_string.html
http://www.algonet.se/~afb/d/dcaf/html/class_string_buffer.html
Every time you hand out a char[], you give the caller a reference to your internal member. Should be a "return str.dup;" :-( Best regards, Stefan
Jul 03 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stefan Zobel wrote:


 Every time you hand out a char[], you give the caller a reference to 
 your internal member. Should be a "return str.dup;" :-(
This goes for most implementations of toString(), I guess ? This actually would be the key issue we are debating here... The char[] that is given out *is* read-only, there's just no way of indicating that - except for the Gentlemen's Agreement. And, no, it should NOT be a dup (as my "StringBuffer" did do that). It's _supposed_ to return a reference to the (immutable) contents. And you could still peek and poke it by casting to char* and changing the memory inside, but that's besides the point here. I don't think that D needs a string class, but "something else" ? I like the current strings, it's just that they are (or: could be) a little dangerous - just like a raw char* in C could be, I guess. But for C/C++ there is "const" - D needs something similar, but better. --anders
Jul 03 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:da8ivk$12cm$1 digitaldaemon.com...
 Stefan Zobel wrote:


 Every time you hand out a char[], you give the caller a reference to your 
 internal member. Should be a "return str.dup;" :-(
This goes for most implementations of toString(), I guess ? This actually would be the key issue we are debating here... The char[] that is given out *is* read-only, there's just no way of indicating that - except for the Gentlemen's Agreement.
Exactly! You can theoretically reproduce String (immutable string value) which will be *completely useles and inneffective*. What is the point to have String which you cannot use e.g. here: FILE * fopen([const] char* path, [const] char* flags); ?
 And, no, it should NOT be a dup (as my "StringBuffer" did do that).
 It's _supposed_ to return a reference to the (immutable) contents.

 And you could still peek and poke it by casting to char* and
 changing the memory inside, but that's besides the point here.


 I don't think that D needs a string class, but "something else" ?


 I like the current strings, it's just that they are (or: could be)
 a little dangerous - just like a raw char* in C could be, I guess.
Agreed, String as a class is not needed in D. But String as an entity consist of two things: and string manipulation buffer (array): char[]. And this *duo* is the must for success.
 But for C/C++ there is "const" - D needs something similar, but better.
D already has better part - in, inout, out. These combined with const *is* better from notational point of view than in current C/C++.
Jul 03 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Andrew Fedoniouk wrote:

But for C/C++ there is "const" - D needs something similar, but better.
D already has better part - in, inout, out. These combined with const *is* better from notational point of view than in current C/C++.
The only problem being that in/out just affects the pointer/array ref, where it works fine already, but not the actual contents of the array... In some ways, that is similar to how passing an object reference to a function allows it to change internal state of the object passed. But the difference is of course that the object is changed through methods while the array passed could be modified "behind your back". So we still need some "mutable" attribute to give to strings/arrays, and something like "char[out] string" might work - but is rather ugly ? and would rather have both "mutable char[]" (as well as "static if"...) Assuming here that C++-style "const" is the default for a parameter, and that it would be more useful to have a keyword for the opposite. But I think that it's a _very_ good chance that this ends up like the booleans, with some syntax approaching the real thing but not enforced. How it is *supposed* to work is pretty clear from the Copy-on-Write ? It's just that there is not too much "checking" from the D compiler... For me it's not really a show-stopper, just a(nother) small annoyance. The string handling in D still rocks when compared to what old C had. --anders
Jul 03 2005
prev sibling parent reply Stefan Zobel <Stefan_member pathlink.com> writes:
In article <da8ivk$12cm$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Stefan Zobel wrote:


 Every time you hand out a char[], you give the caller a reference to 
 your internal member. Should be a "return str.dup;" :-(
This goes for most implementations of toString(), I guess ? This actually would be the key issue we are debating here...
Yep, exactly.
The char[] that is given out *is* read-only, there's just no
way of indicating that - except for the Gentlemen's Agreement.
I understand the "philosophical" point here. I was just pointing out that, technically (current D), it is not.
And, no, it should NOT be a dup (as my "StringBuffer" did do that).
It's _supposed_ to return a reference to the (immutable) contents.
Hhm, "_supposed_". Not sure, if I can follow you here, but that may be because english is not my mother tongue (also didn't take a look at StringBuffer). The fact remains, that (to be really immutable) it must be a dup in D as it is right now.
And you could still peek and poke it by casting to char* and
changing the memory inside, but that's besides the point here.
void main () { String mutableString = new String("immutable!"); writefln(mutableString); char[] ref = mutableString.toString(); ref[9] = '?'; writefln(mutableString); } No "peeking and poking" here, just a realistic use case. But I'm convinced you know that. So, presumably I simply didn't get your point?
I don't think that D needs a string class, but "something else" ?


I like the current strings, it's just that they are (or: could be)
a little dangerous - just like a raw char* in C could be, I guess.


But for C/C++ there is "const" - D needs something similar, but better.

--anders
Agreed, we wouldn't need a string class (could save on all that duping) if we had a way to declare const/immutable/... references in D. Just wanted to remark that String.d isn't immutable, nothing more. No offense intended :) Kind regards, Stefan
Jul 03 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Stefan Zobel wrote:

And you could still peek and poke it by casting to char* and
changing the memory inside, but that's besides the point here.
void main () { String mutableString = new String("immutable!"); writefln(mutableString); char[] ref = mutableString.toString(); ref[9] = '?'; writefln(mutableString); } No "peeking and poking" here, just a realistic use case. But I'm convinced you know that. So, presumably I simply didn't get your point?
I simply meant that even when you *do* have "const char[]" (or similar), you can still (implicitly?) cast it to a pointer in D and change away... Then again, introducing such a new thing would probably be accompanied by "const char*" too, which any "const char[]" would return for .ptr ?
 Agreed, we wouldn't need a string class (could save on all that duping)
 if we had a way to declare const/immutable/... references in D. Just wanted
 to remark that String.d isn't immutable, nothing more. No offense intended :)
As pointed out by others, could take toString out - making it useless. And this is not only "toString", but also toCodePoints and opSlice - and probably most other similar member functions returing arrays... ? They are all read-only and "protected" by the Copy-on-Write convention. --anders
Jul 03 2005
parent Stefan Zobel <Stefan_member pathlink.com> writes:
In article <daali1$5mn$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Stefan Zobel wrote:

And you could still peek and poke it by casting to char* and
changing the memory inside, but that's besides the point here.
void main () { String mutableString = new String("immutable!"); writefln(mutableString); char[] ref = mutableString.toString(); ref[9] = '?'; writefln(mutableString); } No "peeking and poking" here, just a realistic use case. But I'm convinced you know that. So, presumably I simply didn't get your point?
I simply meant that even when you *do* have "const char[]" (or similar), you can still (implicitly?) cast it to a pointer in D and change away... Then again, introducing such a new thing would probably be accompanied by "const char*" too, which any "const char[]" would return for .ptr ?
 Agreed, we wouldn't need a string class (could save on all that duping)
 if we had a way to declare const/immutable/... references in D. Just wanted
 to remark that String.d isn't immutable, nothing more. No offense intended :)
As pointed out by others, could take toString out - making it useless. And this is not only "toString", but also toCodePoints and opSlice - and probably most other similar member functions returing arrays... ? They are all read-only and "protected" by the Copy-on-Write convention. --anders
Ok, point taken. It's a COW string intended to be used as such. Thanks for the clarification. Best regards, Stefan
Jul 04 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message
news:da8but$t3j$1 digitaldaemon.com...
 Walter wrote:

 So I am not understanding why const or immutable is needed for D
strings.
 I've written a number of string processing programs in D (including a
macro
 text processor, and the silly program that transforms newsgroup postings
 into the "archive" pages), and didn't have any difficulty with D
strings.
 They went together with much less effort and far fewer bugs than their
C++
 counterparts.
No offense, but didn't you design the language and string handling ? :-)
Yup (with some help from others like Jan Knepper and Arcane Jill), but it did go through a few iterations.
 I've written several segfaults by changing "readonly" literals, and
 gotten some strange results by setting hash string keys without duping
 them first (and then later changing the value of the string, that is...)
 I also think it's pretty easy to "mess up" when using any array slices.
There is a mindset to COW that takes some getting used to.
 It would be great if there were some "extra mechanism" enforcing CoW.
I agree, but I am not convinced that "const" is it.
 I do understand the desire for const. But there are many different ways
to
 approach the problem, and I'm not willing to just duplicate the C++
const
 with all its weaknesses and problems. There's got to be a better way.
It would nice to come up with an approach that would: a) default local strings/arrays to read-write b) default external parameters to read-only "in"/"out" doesn't really work, since it only affects the array pointer/length and not the actually characters. Maybe something like "char[out] string", but that looks a little like a variable... Anyway, I wouldn't want to see "const" (or "readonly", "immutable") all over the place either - better to have a "readwrite" or "mutable" keyword for the (few?) cases when you *do* want to modify the contents ?
Yes.
 I guess it's the D Gentlemen's Agreement, while keeping on searching.
 (it's easy enough* to implement java.lang.String and StringBuffer in D,
 but I'm still hoping there is some compromise between "C" and "Java")

 --anders

 * PS. Here's one such hack (mostly for the discussion really)
 http://www.algonet.se/~afb/d/dcaf/html/class_string.html
 http://www.algonet.se/~afb/d/dcaf/html/class_string_buffer.html
Jul 03 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <da89e7$s7m$1 digitaldaemon.com>, Walter says...
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:da7ulp$kub$1 digitaldaemon.com...
 ooohh... could you first provide me an option to *declare*
 e.g. slice as immutable thus I'll be able to return it from
 function without duping it? *That* would be optimization.
In following COW principles, you do not need to dup the slice when returning it. The producer of the value doesn't need to dup it, the *consumer* does, and only if the *consumer* modifies it. Taking a slice of an array does not modify it in any way, so no dup is required. So I am not understanding why const or immutable is needed for D strings. I've written a number of string processing programs in D (including a macro text processor, and the silly program that transforms newsgroup postings into the "archive" pages), and didn't have any difficulty with D strings. They went together with much less effort and far fewer bugs than their C++ counterparts.
To me, C++ 'const' just a means of indicating, in code, that a value is not intended to be modifiable. So if I have a string property in a class, I can return a const reference my internal copy and be somewhat assurred that the client will have to make a conscious attempt if he wants to modify the data. This is really only useful for strings IMO in D, as they can be expensive to copy and there's no way to restrict their functionality. But I'm not sure it's worth adding a language feature just to help idiot-proof string use.
I do understand the desire for const. But there are many different ways to
approach the problem, and I'm not willing to just duplicate the C++ const
with all its weaknesses and problems. There's got to be a better way.
I agree. Hopefully, something will present itself. Sean
Jul 03 2005
prev sibling next sibling parent reply AJG <AJG_member pathlink.com> writes:
Hi Walter,

 const is not a physical protection. And never was.
 It is logical declaration of intention:

      I am not going to change this parameter or
      value it is refereing, so, compiler, please,
      warn me if I'll do this accidentally.
Yet the value can change anyway. Another reference can change it, and another thread can change it. It isn't "constant" at all, and cannot be relied on to be constant, even if your program is 100% "const-correct". The C++ const is *completely useless* to the compiler optimizer for that reason.
I can't fathom that the compiler can't make use of the fact that you are telling it: "The following function body will not modify [variable] at all, ever."? Surely this is useful information that can be made into some kind of optimization, specially when ignoring the dangers of threading: I simply don't see why threads even have to come into the picture. You could take a soldering iron and hack memory directly and the runtime won't be able to protect against that. But does it matter? I don't think that's the point of const. It is not a guarantee by the _compiler_ that the value will remain constant. It is a guarantee by the _programmer_ that his function body will not touch the variable. Of course, the compiler (or lexer), should make sure to prevent the programmer from violating his contract via syntax.
A const thing that instead, is a guarantee that the underlying values won't
change, is actually useful. An optimizer can do a lot with it.
But wouldn't such a thing (a runtime-enforced const) cause big performance problems? It would mean the runtime would have to deal with race conditions and thread synchronization for every single const variable and object in memory. That seems awfully slow to me; a gratuitous use of locks and mutexes. If so, this makes for an interesting catch-22. If you implement it, you can optimize, but you get the performance penalty. If you don't implement it, there's no performance penalty, but you can't optimize either. I say forget about the runtime-const. Stick with semantic (compile-time) const, and try to make use of that info to optimize. Forget about threading too, which should make it easier. If the programmer wants to make sure some variable won't change via some other thread, then he should: [a] simply not use it in that thread; or [b] make the function that uses it on that thread take a const; or [c] lock and synchronize it himself individually. As far as references go, you should not (syntactically) be able to make a non-const reference to a const. That should guarantee correctness within the function body. Examples: Pretty simple, if you ask me. You could make "in" = "const" (syntactically) in that sense, which should have always been the default. Or you could do: - No modifier: e.g. func(int a) : This means make a (mutable, independent) copy of the caller's variable. Use dup for arrays, etc. - IN modifier: e.g. func(in int a) : This means const as defined above. Cheers, --AJG.
Jul 02 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message 
news:da7vvd$lm6$1 digitaldaemon.com...
 Hi Walter,

 const is not a physical protection. And never was.
 It is logical declaration of intention:

      I am not going to change this parameter or
      value it is refereing, so, compiler, please,
      warn me if I'll do this accidentally.
Yet the value can change anyway. Another reference can change it, and another thread can change it. It isn't "constant" at all, and cannot be relied on to be constant, even if your program is 100% "const-correct". The C++ const is *completely useless* to the compiler optimizer for that reason.
I can't fathom that the compiler can't make use of the fact that you are telling it: "The following function body will not modify [variable] at all, ever."? Surely this is useful information that can be made into some kind of optimization, specially when ignoring the dangers of threading: I simply don't see why threads even have to come into the picture. You could take a soldering iron and hack memory directly and the runtime won't be able to protect against that. But does it matter? I don't think that's the point of const. It is not a guarantee by the _compiler_ that the value will remain constant. It is a guarantee by the _programmer_ that his function body will not touch the variable. Of course, the compiler (or lexer), should make sure to prevent the programmer from violating his contract via syntax.
A const thing that instead, is a guarantee that the underlying values 
won't
change, is actually useful. An optimizer can do a lot with it.
But wouldn't such a thing (a runtime-enforced const) cause big performance problems? It would mean the runtime would have to deal with race conditions and thread synchronization for every single const variable and object in memory. That seems awfully slow to me; a gratuitous use of locks and mutexes. If so, this makes for an interesting catch-22. If you implement it, you can optimize, but you get the performance penalty. If you don't implement it, there's no performance penalty, but you can't optimize either. I say forget about the runtime-const. Stick with semantic (compile-time) const, and try to make use of that info to optimize. Forget about threading too, which should make it easier. If the programmer wants to make sure some variable won't change via some other thread, then he should: [a] simply not use it in that thread; or [b] make the function that uses it on that thread take a const; or [c] lock and synchronize it himself individually. As far as references go, you should not (syntactically) be able to make a non-const reference to a const. That should guarantee correctness within the function body. Examples: Pretty simple, if you ask me. You could make "in" = "const" (syntactically) in that sense, which should have always been the default. Or you could do: - No modifier: e.g. func(int a) : This means make a (mutable, independent) copy of the caller's variable. Use dup for arrays, etc. - IN modifier: e.g. func(in int a) : This means const as defined above.
Thanks, AJG, excellent statement. Except final :) in, inout and out in function parameters defines direction. This quite different from const and let's don't mix it. See, declaration: void toLower(in char[] str) means that toLower function will not change length of the str but allowed to change its content. Reasonable? Yes. Next step, this declaration: char[] toLower(in const char[] str) means that: 1) this toLower will not change str. nor length nor its content. 2) It returns mutable array and caller is free to use it in the way it wants - it may own it, store it, whatever. These two functions will peacefuly coexist in phobos as they have different signatures. Developer can do *optimal* choice. Signature: const char[] getDir(in const char[] path) means: getDir will not do anything with path - will just return const slice. Signature: void splitPath(in const char[] path, out const char[] dir, out const char[] filename, out const char[] ext) Means it will not touch path and will return constant slices representing path parts. Signature: void splitPath(in const char[] path, out char[] dir, out char[] filename, out char[] ext) Means it will not touch path and will return arrays - copies of path parts - caller is free to own them. Anyone brave here to tell me (us with AJG :) that all this above have nothing common with optimization?
Jul 03 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message
news:da7vvd$lm6$1 digitaldaemon.com...
Yet the value can change anyway. Another reference can change it, and
another thread can change it. It isn't "constant" at all, and cannot be
relied on to be constant, even if your program is 100% "const-correct".
The
C++ const is *completely useless* to the compiler optimizer for that
reason.
 I can't fathom that the compiler can't make use of the fact that you are
telling
 it: "The following function body will not modify [variable] at all,
ever."? Consider the following C++ function: int foo(const int *p, int *q) { int i = *p; *q = 3; return *p; } At the return statement, could we replace *p with i, thereby saving ourselves a dereference operation? After all, p points to "const" data, right? Wrong. Consider calling foo() this way: int a[3]; ... foo(a, a); Since p and q now hold the same value, *q = 3; will change the contents of what p points to. This code is perfectly legal C++, and is "const-correct". It happens often enough in real code, too, as I discovered when trying to implement this optimization.
Jul 03 2005
next sibling parent reply AJG <AJG_member pathlink.com> writes:
In article <da88rb$ruj$1 digitaldaemon.com>, Walter says...
"AJG" <AJG_member pathlink.com> wrote in message
news:da7vvd$lm6$1 digitaldaemon.com...
Yet the value can change anyway. Another reference can change it, and
another thread can change it. It isn't "constant" at all, and cannot be
relied on to be constant, even if your program is 100% "const-correct".
The
C++ const is *completely useless* to the compiler optimizer for that
reason.
 I can't fathom that the compiler can't make use of the fact that you are
telling
 it: "The following function body will not modify [variable] at all,
ever."? Consider the following C++ function: int foo(const int *p, int *q) { int i = *p; *q = 3; return *p; }
    int a[3];
    ...
    foo(a, a);
Hm... that's an interesting situation. Ok, say pointers are not considered, because they are inherently unsafe anyway. Let's take only regular in/out/inout variables. Could the same trick be done simply with these?
This code is perfectly legal C++, and is "const-correct". It happens often
enough in real code, too, as I discovered when trying to implement this
optimization.
It's possible that such code, although legal, is simply bad code that can't be protected against. The function documentation should state which variables shouldn't be the same. I think it's simply undefined behaviour. I dunno if all optimization should be off simply because of the occasinal badly coded, documented and used function. It's kind of like modifying the iterating array inside a foreach - perfectly valid too, but that's going to be ugly (perhaps that should be made illegal too, btw). Or for example, sending the same variable to multiple parameters of a string-manipulation (str*) function. Consider this: // char *str = "Some text"; // str = strcat(str, str); --------------------------- Once again, what if pointers are not considered, would this make things easier? If you take out pointers, couldn't the compiler detect if you were sending the same variable to multiple differently-accessable parameters? Cheers, --AJG.
Jul 03 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message
news:da8vgt$1bos$1 digitaldaemon.com...
 In article <da88rb$ruj$1 digitaldaemon.com>, Walter says...
"AJG" <AJG_member pathlink.com> wrote in message
news:da7vvd$lm6$1 digitaldaemon.com...
Yet the value can change anyway. Another reference can change it, and
another thread can change it. It isn't "constant" at all, and cannot
be
relied on to be constant, even if your program is 100%
"const-correct".
The
C++ const is *completely useless* to the compiler optimizer for that
reason.
 I can't fathom that the compiler can't make use of the fact that you
are
telling
 it: "The following function body will not modify [variable] at all,
ever."? Consider the following C++ function: int foo(const int *p, int *q) { int i = *p; *q = 3; return *p; }
    int a[3];
    ...
    foo(a, a);
Hm... that's an interesting situation. Ok, say pointers are not
considered,
 because they are inherently unsafe anyway. Let's take only regular
in/out/inout
 variables. Could the same trick be done simply with these?
With simple value variables, no. But that isn't interesting, as there isn't much of any point to "const" value variables as function parameters. With reference parameters, yes, it can happen in the same way.
This code is perfectly legal C++, and is "const-correct". It happens
often
enough in real code, too, as I discovered when trying to implement this
optimization.
It's possible that such code, although legal, is simply bad code that
can't be
 protected against. The function documentation should state which variables
 shouldn't be the same. I think it's simply undefined behaviour.

 I dunno if all optimization should be off simply because of the occasinal
badly
 coded, documented and used function.

 It's kind of like modifying the iterating array inside a foreach -
perfectly
 valid too, but that's going to be ugly (perhaps that should be made
illegal too,
 btw). Or for example, sending the same variable to multiple parameters of
a
 string-manipulation (str*) function. Consider this:

 // char *str = "Some text";
 // str = strcat(str, str);

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

 Once again, what if pointers are not considered, would this make things
easier?
 If you take out pointers, couldn't the compiler detect if you were sending
the
 same variable to multiple differently-accessable parameters?
The compiler cannot detect it in the general case, as a function may receive a non-const reference to the same data by an arbitrarilly complex path. What you're suggesting is different from C++ "const" - you're suggesting that const actually mean "constant". This is definitely more interesting that C++ const, but then there's the problem of undefined behavior and trying to detect it.
Jul 03 2005
parent reply AJG <AJG_member pathlink.com> writes:
Hi Walter,

 Once again, what if pointers are not considered, would this make things
easier?
 If you take out pointers, couldn't the compiler detect if you were sending
the
 same variable to multiple differently-accessable parameters?
The compiler cannot detect it in the general case, as a function may receive a non-const reference to the same data by an arbitrarilly complex path.
I know I'm pushing it here, but can't the compiler follow that arbitrarily complex path (excluding pointers)?
What you're suggesting is different from C++ "const" - you're suggesting
that const actually mean "constant". This is definitely more interesting
that C++ const, but then there's the problem of undefined behavior and
trying to detect it.
Hm... perhaps. Ok, first let me see if I understand your point: You say: C++ const, which is semantic only, is useless for optimizations. You say: Implementing C++ const in D would be equally useless re: optimizations. I say: const should be _always_ about semantics ("correctness"), and _if possible_ provide optimizations. You say: That is not good enough, we need correctness and optimization. Is that correct? So, if you can solve the arbitrarily complex path problem, you get the both of both worlds, right? I dunno if this is possible, just thinking out loud. If not syntactically, could it be done via whole-program static analysis? Thanks, --AJG.
Jul 03 2005
parent "Walter" <newshound digitalmars.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message
news:da9ig8$1vpg$1 digitaldaemon.com...
 Once again, what if pointers are not considered, would this make things
easier?
 If you take out pointers, couldn't the compiler detect if you were
sending
the
 same variable to multiple differently-accessable parameters?
The compiler cannot detect it in the general case, as a function may
receive
a non-const reference to the same data by an arbitrarilly complex path.
I know I'm pushing it here, but can't the compiler follow that arbitrarily complex path (excluding pointers)?
If it could, the program could be executed at compile time rather than run time <g>.
What you're suggesting is different from C++ "const" - you're suggesting
that const actually mean "constant". This is definitely more interesting
that C++ const, but then there's the problem of undefined behavior and
trying to detect it.
Hm... perhaps. Ok, first let me see if I understand your point: You say: C++ const, which is semantic only, is useless for optimizations. You say: Implementing C++ const in D would be equally useless re:
optimizations.
 I say:   const should be _always_ about semantics ("correctness"), and _if
 possible_ provide optimizations.
 You say: That is not good enough, we need correctness and optimization.

 Is that correct?
From correctness comes the optimizations. C++ doesn't implement correctness, as my example showed.
 If not syntactically, could it be done via whole-program static analysis?
No.
Jul 03 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da88rb$ruj$1 digitaldaemon.com...
 "AJG" <AJG_member pathlink.com> wrote in message
 news:da7vvd$lm6$1 digitaldaemon.com...
Yet the value can change anyway. Another reference can change it, and
another thread can change it. It isn't "constant" at all, and cannot be
relied on to be constant, even if your program is 100% "const-correct".
The
C++ const is *completely useless* to the compiler optimizer for that
reason.
 I can't fathom that the compiler can't make use of the fact that you are
telling
 it: "The following function body will not modify [variable] at all,
ever."? Consider the following C++ function: int foo(const int *p, int *q) { int i = *p; *q = 3; return *p; } At the return statement, could we replace *p with i, thereby saving ourselves a dereference operation? After all, p points to "const" data, right? Wrong. Consider calling foo() this way: int a[3]; ... foo(a, a); Since p and q now hold the same value, *q = 3; will change the contents of what p points to. This code is perfectly legal C++, and is "const-correct". It happens often enough in real code, too, as I discovered when trying to implement this optimization.
Walter, it is enough for me to know that int foo(const int *p, int *q) { int i = *p; *q = 3; .... 200 lines of code return *p; } will not change *p. I am not asking for optimization here. Optimization happened before - when I wrote this fucntion declaration using const parameters. I understand that you focused on optimiziation as compiler and codegenerator writer. This is perfectly good and thank you for that. But const is a matter of language design and not about optimization. Well not exactly as if I will write both: int foo(const int *p, int *q) int foo(int *p, int *q) then I will make an act of optimization on the design level. Again: from the point of optimization 'public', 'private' attributes are almost worthless. But despite of that they are in the language. const is the same - it is a contract. Any argument that you can *intentionally* break constness are true. The same apply to visibility attributes. Andrew.
Jul 03 2005
next sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:da93ap$1g54$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message 
 news:da88rb$ruj$1 digitaldaemon.com...
 "AJG" <AJG_member pathlink.com> wrote in message
 news:da7vvd$lm6$1 digitaldaemon.com...
Yet the value can change anyway. Another reference can change it, and
another thread can change it. It isn't "constant" at all, and cannot be
relied on to be constant, even if your program is 100% "const-correct".
The
C++ const is *completely useless* to the compiler optimizer for that
reason.
 I can't fathom that the compiler can't make use of the fact that you are
telling
 it: "The following function body will not modify [variable] at all,
ever."? Consider the following C++ function: int foo(const int *p, int *q) { int i = *p; *q = 3; return *p; } At the return statement, could we replace *p with i, thereby saving ourselves a dereference operation? After all, p points to "const" data, right? Wrong. Consider calling foo() this way: int a[3]; ... foo(a, a); Since p and q now hold the same value, *q = 3; will change the contents of what p points to. This code is perfectly legal C++, and is "const-correct". It happens often enough in real code, too, as I discovered when trying to implement this optimization.
Walter, it is enough for me to know that int foo(const int *p, int *q) { int i = *p; *q = 3; .... 200 lines of code return *p; } will not change *p. I am not asking for optimization here. Optimization happened before - when I wrote this fucntion declaration using const parameters.
The whole problem is, with the C++ rules, the optimizations cannot even be done by the code generator - you may think you've optimized something with const, but in reality the code generator cannot make use of it because of how const is implimented in C++ and the compiler cannot figure out 100% for certain what is being done with referenced data.
 I understand that you focused on optimiziation as compiler and 
 codegenerator
 writer. This is perfectly good and thank you for that.
What I think Walter has in mind with his "explicit in" proposal for D is "constness" while still allowing for the optimizations that C++ can't do, or at least can't do without making the compiler much more complicated.
 But const is a matter of language design and not about optimization.
 Well not exactly as if I will write both:

 int foo(const int *p, int *q)
 int foo(int *p, int *q)

 then I will make an act of optimization on the design level.

 Again: from the point of optimization 'public', 'private' attributes are 
 almost worthless.
'private' and 'package' data members may have some optimizations applied because of the protection attribute scope rules. private and package methods can't be virtual, so there are some optimizations having to do with inlining and the vtable that can be (and are) done by the compiler, because 'private' or 'package' guarantees that those are not virtual methods.
 But despite of that they are in the language. const is the same - it is a 
 contract.
 Any argument that you can *intentionally* break constness are true.
 The same apply to visibility attributes.

 Andrew.

 
Jul 03 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:da95on$1jff$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:da93ap$1g54$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message 
 news:da88rb$ruj$1 digitaldaemon.com...
 "AJG" <AJG_member pathlink.com> wrote in message
 news:da7vvd$lm6$1 digitaldaemon.com...
Yet the value can change anyway. Another reference can change it, and
another thread can change it. It isn't "constant" at all, and cannot 
be
relied on to be constant, even if your program is 100% 
"const-correct".
The
C++ const is *completely useless* to the compiler optimizer for that
reason.
 I can't fathom that the compiler can't make use of the fact that you 
 are
telling
 it: "The following function body will not modify [variable] at all,
ever."? Consider the following C++ function: int foo(const int *p, int *q) { int i = *p; *q = 3; return *p; } At the return statement, could we replace *p with i, thereby saving ourselves a dereference operation? After all, p points to "const" data, right? Wrong. Consider calling foo() this way: int a[3]; ... foo(a, a); Since p and q now hold the same value, *q = 3; will change the contents of what p points to. This code is perfectly legal C++, and is "const-correct". It happens often enough in real code, too, as I discovered when trying to implement this optimization.
Walter, it is enough for me to know that int foo(const int *p, int *q) { int i = *p; *q = 3; .... 200 lines of code return *p; } will not change *p. I am not asking for optimization here. Optimization happened before - when I wrote this fucntion declaration using const parameters.
The whole problem is, with the C++ rules, the optimizations cannot even be done by the code generator - you may think you've optimized something with const, but in reality the code generator cannot make use of it because of how const is implimented in C++ and the compiler cannot figure out 100% for certain what is being done with referenced data.
Again I am willing to write to functions which provided together will give an optimal choice: void toUpper( in char[] strbuf ) // inplace char[] toUpper( in const char[] str ) // return brand new. I am free to chose optimal function for particular case. And while implementing it compiler will not allow me to change *accidentally* value of str. This is *deterministic* optimization. codegenerator *may* do optimization. And may not. const is not about codegenerator optimiziation. Dot. Forget about it.
 I understand that you focused on optimiziation as compiler and 
 codegenerator
 writer. This is perfectly good and thank you for that.
What I think Walter has in mind with his "explicit in" proposal for D is "constness" while still allowing for the optimizations that C++ can't do, or at least can't do without making the compiler much more complicated.
 But const is a matter of language design and not about optimization.
 Well not exactly as if I will write both:

 int foo(const int *p, int *q)
 int foo(int *p, int *q)

 then I will make an act of optimization on the design level.

 Again: from the point of optimization 'public', 'private' attributes are 
 almost worthless.
'private' and 'package' data members may have some optimizations applied because of the protection attribute scope rules. private and package methods can't be virtual, so there are some optimizations having to do with inlining and the vtable that can be (and are) done by the compiler, because 'private' or 'package' guarantees that those are not virtual methods.
I think that you a wrong here as following: import std.stdio; class One { package int foo() { return 1; } } class Two: One { override package int foo() { return 2; } } int main() { Two t = new Two; return t.foo(); } compiles just fine.
 But despite of that they are in the language. const is the same - it is a 
 contract.
 Any argument that you can *intentionally* break constness are true.
 The same apply to visibility attributes.

 Andrew.
Jul 03 2005
parent reply "Dave" <Dave_member pathlink.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:da9g47$1tfc$1 digitaldaemon.com...
 "Dave" <Dave_member pathlink.com> wrote in message 
 news:da95on$1jff$1 digitaldaemon.com...
 The whole problem is, with the C++ rules, the optimizations cannot even 
 be done by the code generator - you may think you've optimized something 
 with const, but in reality the code generator cannot make use of it 
 because of how const is implimented in C++ and the compiler cannot figure 
 out 100% for certain what is being done with referenced data.
Again I am willing to write to functions which provided together will give an optimal choice: void toUpper( in char[] strbuf ) // inplace char[] toUpper( in const char[] str ) // return brand new.
I understand - I think we're all looking for some way to implement "constness" in a way that is better, for at least the majority of cases, than how C++ does it. From Walter's earlier post, it appears that overloading based on some type of "const" storage modifier is not going to happen, so I'll take what I can get in this regard, especially if it helps compiler implementors do their job better because then I get better tools. Walter wants D's "constness" to be taken as a semantic guarantee of some value, and I agree with him on that, because then it's of more value to both the compiler and someone debugging code (const the way it is in C++ can actually hide bugs). I also agree with the notion that C++ constness is a mess and that is one of the major reasons why I want D to succeed, so I don't have to deal with that as it is. I take it you basically want C++ constness in D - I just have to disagree with that because that's one of the things I think needs to be done better.
 I am free to chose optimal function for particular case.
 And while implementing it compiler will not allow
 me to change *accidentally* value of str.

 private and package methods can't be virtual, so there are some 
 optimizations having to do with inlining and the vtable that can be (and 
 are) done by the compiler, because 'private' or 'package' guarantees that 
 those are not virtual methods.
I think that you a wrong here as following: import std.stdio; class One { package int foo() { return 1; } } class Two: One { override package int foo() { return 2; } } int main() { Two t = new Two; return t.foo(); } compiles just fine.
Try this: 1 1 vs. this: 2 1 ;--- import std.stdio; class One { version(_package) package int foo() { return 1; } else public int foo() { return 1; } } class Two: One { version(_package) override package int foo() { return 2; } else override public int foo() { return 2; } } void main() { Two t = new Two; writefln((cast(One)t).foo()); One o = new One; writefln("%d\n",(cast(One)o).foo()); }
Jul 03 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:da9jup$21h4$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:da9g47$1tfc$1 digitaldaemon.com...
 "Dave" <Dave_member pathlink.com> wrote in message 
 news:da95on$1jff$1 digitaldaemon.com...
 The whole problem is, with the C++ rules, the optimizations cannot even 
 be done by the code generator - you may think you've optimized something 
 with const, but in reality the code generator cannot make use of it 
 because of how const is implimented in C++ and the compiler cannot 
 figure out 100% for certain what is being done with referenced data.
Again I am willing to write to functions which provided together will give an optimal choice: void toUpper( in char[] strbuf ) // inplace char[] toUpper( in const char[] str ) // return brand new.
I understand - I think we're all looking for some way to implement "constness" in a way that is better, for at least the majority of cases, than how C++ does it. From Walter's earlier post, it appears that overloading based on some type of "const" storage modifier is not going to happen, so I'll take what I can get in this regard, especially if it helps compiler implementors do their job better because then I get better tools.
'"const" storage modifier is not going to happen,...' Then page http://www.digitalmars.com/d/comparison.html needs to be updated by features which are impossible to implement in D in principle. Just for the sake of truth.
 Walter wants D's "constness" to be taken as a semantic guarantee of some 
 value, and I agree with him on that, because then it's of more value to 
 both the compiler and someone debugging code (const the way it is in C++ 
 can actually hide bugs). I also agree with the notion that C++ constness 
 is a mess and that is one of the major reasons why I want D to succeed, so 
 I don't have to deal with that as it is.

 I take it you basically want C++ constness in D - I just have to disagree 
 with that because that's one of the things I think needs to be done 
 better.
The ultimate const protection can be done only on hardware level (I mean without compromises) which is not the case for D. About stylistic: I will repeat again: the best way (near ideal) is to be able to say something like this: type[def] string: char[] { private opIndexAssign(...) // disabled public string opSlice() // returns immutable slice.... ... etc... } It is more universal but significantly more complex. But I am pretty sure it is a future - to be able to fine tune type redefinitions of primitives. For a while I propose to introduce
 I am free to chose optimal function for particular case.
 And while implementing it compiler will not allow
 me to change *accidentally* value of str.

 private and package methods can't be virtual, so there are some 
 optimizations having to do with inlining and the vtable that can be (and 
 are) done by the compiler, because 'private' or 'package' guarantees 
 that those are not virtual methods.
I think that you a wrong here as following: import std.stdio; class One { package int foo() { return 1; } } class Two: One { override package int foo() { return 2; } } int main() { Two t = new Two; return t.foo(); } compiles just fine.
Try this: 1 1 vs. this: 2 1 ;--- import std.stdio; class One { version(_package) package int foo() { return 1; } else public int foo() { return 1; } } class Two: One { version(_package) override package int foo() { return 2; } else override public int foo() { return 2; } } void main() { Two t = new Two; writefln((cast(One)t).foo()); One o = new One; writefln("%d\n",(cast(One)o).foo()); }
Nice! Just perfect! And those people are telling me that const hides possible errors? :-)))
Jul 03 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:da93ap$1g54$1 digitaldaemon.com...
 Walter, it is enough for me to know that

 int foo(const int *p, int *q)
    {
        int i = *p;
        *q = 3;

        .... 200 lines of code

        return *p;
    }

 will not change *p. I am not asking for optimization here. Optimization
 happened before - when I wrote this fucntion declaration using const
 parameters.

 I understand that you focused on optimiziation as compiler and
codegenerator
 writer. This is perfectly good and thank you for that.
The optimization issue is a symptom of the problem with const, not the problem itself. The inability to make *any* use of const for the compiler to learn something about the program is, to me anyway, indicative that the semantic value of const is not there. Optimizers work by being able to prove certain properties of code to be true. At a higher level, being able to prove certain things about a program is important for all kinds of code analysis tools, like verifiers, etc. Being able to prove something about a program is also useful for the programmer, as knowing something that must be true about a piece of code is the first step to debugging it. C++ const doesn't enable proving anything about the const reference. The optimizer can't prove the values won't change, and *neither can the programmer* rely on it. If I see a const reference in C++ code, I don't know if it really is constant or not. As a programmer looking at someone else's code, it offers no value.
 But const is a matter of language design and not about optimization.
 Well not exactly as if I will write both:

 int foo(const int *p, int *q)
 int foo(int *p, int *q)

 then I will make an act of optimization on the design level.

 Again: from the point of optimization 'public', 'private' attributes are
 almost worthless.
 But despite of that they are in the language. const is the same - it is a
 contract.
 Any argument that you can *intentionally* break constness are true.
 The same apply to visibility attributes.
My point (with the example given) is you are NOT breaking const. The code is legal, supported and is const-correct. It's not like const_cast, which is known to be an escape from const, can be grepped for, and can be warned about. There is no commonly accepted C++ convention that says such code is bad form, undefined, etc. And yes, these things do appear in real, working, production code, as I found out when attempting to use const in the optimizer. The only way "const" can be constant in C++ is if you follow an informal convention for your own code that is not enforced by the compiler or the language or by any third party whose code you might wish to use. You cannot assume that const is constant..
Jul 03 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da99a9$1n0q$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da93ap$1g54$1 digitaldaemon.com...
 Walter, it is enough for me to know that

 int foo(const int *p, int *q)
    {
        int i = *p;
        *q = 3;

        .... 200 lines of code

        return *p;
    }

 will not change *p. I am not asking for optimization here. Optimization
 happened before - when I wrote this fucntion declaration using const
 parameters.

 I understand that you focused on optimiziation as compiler and
codegenerator
 writer. This is perfectly good and thank you for that.
The optimization issue is a symptom of the problem with const, not the problem itself. The inability to make *any* use of const for the compiler to learn something about the program is, to me anyway, indicative that the semantic value of const is not there. Optimizers work by being able to prove certain properties of code to be true. At a higher level, being able to prove certain things about a program is important for all kinds of code analysis tools, like verifiers, etc. Being able to prove something about a program is also useful for the programmer, as knowing something that must be true about a piece of code is the first step to debugging it. C++ const doesn't enable proving anything about the const reference. The optimizer can't prove the values won't change, and *neither can the programmer* rely on it. If I see a const reference in C++ code, I don't know if it really is constant or not. As a programmer looking at someone else's code, it offers no value.
True. Except of the last statement: "As a programmer looking at someone else's code, it offers no value." When I am looking on: char[] toStringz(const char[] s) I can tell that: 1) function designed to do not change 's' 2) body of the function passed through compiler - it not contains stupid mistakes inside. Currently I am looking on char* toStringz(char[] s) and trying to guess - what a hell it is doing with my 's'? And finally I can see there memcpy from my friend - C runtime which I know declared as memcpy(void* dst, const void* src, size_t sz)... Could you please do the same? Without it DbC is not full in D.
 But const is a matter of language design and not about optimization.
 Well not exactly as if I will write both:

 int foo(const int *p, int *q)
 int foo(int *p, int *q)

 then I will make an act of optimization on the design level.

 Again: from the point of optimization 'public', 'private' attributes are
 almost worthless.
 But despite of that they are in the language. const is the same - it is a
 contract.
 Any argument that you can *intentionally* break constness are true.
 The same apply to visibility attributes.
My point (with the example given) is you are NOT breaking const. The code is legal, supported and is const-correct. It's not like const_cast, which is known to be an escape from const, can be grepped for, and can be warned about. There is no commonly accepted C++ convention that says such code is bad form, undefined, etc. And yes, these things do appear in real, working, production code, as I found out when attempting to use const in the optimizer. The only way "const" can be constant in C++ is if you follow an informal convention for your own code that is not enforced by the compiler or the language or by any third party whose code you might wish to use. You cannot assume that const is constant..
Exactly! And this is huge. If *you* will write: int foo(const char[] s) then I will trust you - Walter made as much as possible to ensure that foo is not changing s. So I don't need to waste my time digging inside *each* string function in Phobos. Ben propose to use 'to' for that... Is it better or what? Will you also implement "if function name starts from 'to' then ..."? Trying to optimize everything is good but close to "Road to hell is paved by good wishes". Andrew.
Jul 03 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:da9sbs$29to$1 digitaldaemon.com...
 True.
 Except of the last statement:
 "As a programmer looking at someone else's code, it offers no value."

 When I am looking on:

 char[] toStringz(const char[] s)

 I can tell that:

 1) function designed to do not change 's'
 2) body of the function passed through compiler -
     it not contains stupid mistakes inside.
I will argue that you cannot tell that - especially if you are looking for bugs. The language offers no guarantees about const, so when you're going bug hunting, const is not helpful.
 Currently I am looking on

 char* toStringz(char[] s)

 and trying to guess - what a hell it is doing with my 's'?
I understand it can be helpful there, but I don't think it is as helpful as you do. I think there's a better way here somewhere, if we can find it.
Jul 04 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:dach1f$1u8t$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da9sbs$29to$1 digitaldaemon.com...
 True.
 Except of the last statement:
 "As a programmer looking at someone else's code, it offers no value."

 When I am looking on:

 char[] toStringz(const char[] s)

 I can tell that:

 1) function designed to do not change 's'
 2) body of the function passed through compiler -
     it not contains stupid mistakes inside.
I will argue that you cannot tell that - especially if you are looking for bugs. The language offers no guarantees about const, so when you're going bug hunting, const is not helpful.
const helps me to do not do bugs. To change what is not designed to be changed. From the very beginning - at planning level. Hunting is a different story. But again such simple (well, from external look) preventive method can narrow the bug field a lot. DbC methods in D are good, but if code designer will not cover all conditions carefully then they at least meaningless if not worse...
 Currently I am looking on

 char* toStringz(char[] s)

 and trying to guess - what a hell it is doing with my 's'?
I understand it can be helpful there, but I don't think it is as helpful as you do. I think there's a better way here somewhere, if we can find it.
Yep, so far I can see three methods only. Hope somebody will add more. First is straightforward reproduction of const in C++ with all bells and whistles. Second is already defined in "Round III. Brainstrom...." (Explicit contsness, variant I) Third one I've already mentioned somewhere here and going to formalize today also. I like explicit contsness variants as more I would say D-ish (grammatically pure) and easily implementable - read reliable. But again it is my personal opinion only - means can be not perfect. Andrew.
Jul 04 2005
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Well, now, I have a question.  What does this say:

char* toStringz(in char[] s)

As compared to:

char* toStringz(char[] s)

Or:

char* toStringz(inout char[] s)

Since the in is explicitly specified (even if it is implicit) you can 
easily tell that the argument is meant not to modify the data pointed 
to.  If it says inout, then you can assume it returns and modifies the 
string.

It may not mean that it CAN'T change s, but there's only so much you can 
get out of stupid programmers.  In some cases, it's just a simple matter 
of knowing what you're doing.

-[Unknown]


 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da9sbs$29to$1 digitaldaemon.com...
 
True.
Except of the last statement:
"As a programmer looking at someone else's code, it offers no value."

When I am looking on:

char[] toStringz(const char[] s)

I can tell that:

1) function designed to do not change 's'
2) body of the function passed through compiler -
    it not contains stupid mistakes inside.
I will argue that you cannot tell that - especially if you are looking for bugs. The language offers no guarantees about const, so when you're going bug hunting, const is not helpful.
Currently I am looking on

char* toStringz(char[] s)

and trying to guess - what a hell it is doing with my 's'?
I understand it can be helpful there, but I don't think it is as helpful as you do. I think there's a better way here somewhere, if we can find it.
Jul 04 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <da88rb$ruj$1 digitaldaemon.com>, Walter says...
Consider the following C++ function:

    int foo(const int *p, int *q)
    {
        int i = *p;
        *q = 3;
        return *p;
    }

At the return statement, could we replace *p with i, thereby saving
ourselves a dereference operation? After all, p points to "const" data,
right? Wrong. Consider calling foo() this way:

    int a[3];
    ...
    foo(a, a);

Since p and q now hold the same value, *q = 3; will change the contents of
what p points to.

This code is perfectly legal C++, and is "const-correct". It happens often
enough in real code, too, as I discovered when trying to implement this
optimization.
Why do I suddenly feel like we're moving towards defining 'restrict' in D? :) Sean
Jul 03 2005
parent Dave <Dave_member pathlink.com> writes:
In article <da9716$1knv$1 digitaldaemon.com>, Sean Kelly says...
In article <da88rb$ruj$1 digitaldaemon.com>, Walter says...
Consider the following C++ function:

    int foo(const int *p, int *q)
    {
        int i = *p;
        *q = 3;
        return *p;
    }

At the return statement, could we replace *p with i, thereby saving
ourselves a dereference operation? After all, p points to "const" data,
right? Wrong. Consider calling foo() this way:

    int a[3];
    ...
    foo(a, a);

Since p and q now hold the same value, *q = 3; will change the contents of
what p points to.

This code is perfectly legal C++, and is "const-correct". It happens often
enough in real code, too, as I discovered when trying to implement this
optimization.
Why do I suddenly feel like we're moving towards defining 'restrict' in D? :) Sean
Take a peek in the archives on that subject - I don't think you need to worry about that <g> - Dave
Jul 03 2005
prev sibling parent reply Nick <Nick_member pathlink.com> writes:
In article <da7pp5$i06$1 digitaldaemon.com>, Walter says...
Yet the value can change anyway. Another reference can change it, and
another thread can change it. It isn't "constant" at all, and cannot be
relied on to be constant, even if your program is 100% "const-correct".
That is true, but also in fact completly irrelevant. I think you might have misunderstood the intention of the const keyword in C++. It's not meant to be, and has never been meant to be, a guarantee to the internals of the function that "this value will not change". It's not supposed to protect the INSIDE of the function from the outside world, but quite the opposite. It's a guarantee (or contract, if you will) with the code OUTSIDE the function (ie. the caller) that "THIS function will never change this value." What happens in other threads and other references has no relevance to this contract. Also, your example with foo(a,a) is ok, since when you (the caller) send 'a' as the second (non-const) parameter, the function is 'allowed' to change it. Thus the function has not broken the contract. I am not arguing for or against const in D here. My experience with it in C++ has been pretty much the same as yours, and so I am not really convinced of it's usefulness. But your argument really attacks a use of 'const' that was never intended, and thus is not a very good argument. Nick
Jul 03 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Nick" <Nick_member pathlink.com> wrote in message
news:da9dfv$1r9p$1 digitaldaemon.com...
 In article <da7pp5$i06$1 digitaldaemon.com>, Walter says...
Yet the value can change anyway. Another reference can change it, and
another thread can change it. It isn't "constant" at all, and cannot be
relied on to be constant, even if your program is 100% "const-correct".
That is true, but also in fact completly irrelevant. I think you might
have
 misunderstood the intention of the const keyword in C++. It's not meant to
be,
 and has never been meant to be, a guarantee to the internals of the
function
 that "this value will not change". It's not supposed to protect the INSIDE
of
 the function from the outside world, but quite the opposite. It's a
guarantee
 (or contract, if you will) with the code OUTSIDE the function (ie. the
caller)
 that "THIS function will never change this value." What happens in other
threads
 and other references has no relevance to this contract. Also, your example
with
 foo(a,a) is ok, since when you (the caller) send 'a' as the second
(non-const)
 parameter, the function is 'allowed' to change it. Thus the function has
not
 broken the contract.

 I am not arguing for or against const in D here. My experience with it in
C++
 has been pretty much the same as yours, and so I am not really convinced
of it's
 usefulness. But your argument really attacks a use of 'const' that was
never
 intended, and thus is not a very good argument.
You do make a good point.
Jul 03 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Sun, 3 Jul 2005 15:05:20 -0700, Walter <newshound digitalmars.com>  
wrote:
 "Nick" <Nick_member pathlink.com> wrote in message
 news:da9dfv$1r9p$1 digitaldaemon.com...
 In article <da7pp5$i06$1 digitaldaemon.com>, Walter says...
Yet the value can change anyway. Another reference can change it, and
another thread can change it. It isn't "constant" at all, and cannot be
relied on to be constant, even if your program is 100% "const-correct".
That is true, but also in fact completly irrelevant. I think you might
have
 misunderstood the intention of the const keyword in C++. It's not meant  
 to
be,
 and has never been meant to be, a guarantee to the internals of the
function
 that "this value will not change". It's not supposed to protect the  
 INSIDE
of
 the function from the outside world, but quite the opposite. It's a
guarantee
 (or contract, if you will) with the code OUTSIDE the function (ie. the
caller)
 that "THIS function will never change this value." What happens in other
threads
 and other references has no relevance to this contract. Also, your  
 example
with
 foo(a,a) is ok, since when you (the caller) send 'a' as the second
(non-const)
 parameter, the function is 'allowed' to change it. Thus the function has
not
 broken the contract.

 I am not arguing for or against const in D here. My experience with it  
 in
C++
 has been pretty much the same as yours, and so I am not really convinced
of it's
 usefulness. But your argument really attacks a use of 'const' that was
never
 intended, and thus is not a very good argument.
You do make a good point.
This is the same point I've tried to make in the past. To me 'in' is part of the function contract stating I will only 'read' this parameter. I had a DBC style idea for detecting modification to 'in' parameters, it went: import std.stdio; import std.string; import std.c.stdlib; void main() { char[] a = "regan"; foo(a); } void* cmp = null; void foo(char[] string) in { cmp = realloc(cmp,string.sizeof); memcpy(cmp,&string,string.sizeof); } out { assert(memcmp(cmp,&string,string.sizeof) == 0); } body { //this causes the assert, remove it, no assert. string.length = 20; } The compiler could concievably insert these checks itself. Of course, this only detects changes to the variable itself be it a reference, pointer, int etc. It does not address the other desire, to protect the data referenced by the variable. Regan
Jul 03 2005
prev sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da6k71$11rs$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:da4afr$24jc$1 digitaldaemon.com...
 How would this cover the following case that Walter's proposal covers:
 class A { int x; }
 void foo(in A obj){
   int y = obj.x;
   // do whatever you want...
   assert( obj.x == y );
 }
 void main() {
   A obj = new A;
   foo(obj); // says it doesn't change obj
 }
 Is it practical to force A to implement some immutability just because 
 foo
 doesn't change its inputs? I'm not saying Walter's proposal is prefect.
It's
 very strong for foo to say no other thread or reference will change obj
 since it has no control over what other threads are doing. I would be
taking
 pretty much blind leap of faith when declaring an object reference as 
 'in'
 and saying that no other thread is stepping on that object during the 
 call
 lifetime.
You're right. I have misgivings about it for that reason. On the other hand, look at C++ "const". Nothing about "const" says that some other thread or reference cannot change the value out from under you at any moment. Furthermore, it can be cast away and modified anyway. The semantic value of C++ "const" is essentially zip. This is why I am often flummoxed why it is given such weight in C++.
It is equally probable that another thread could step on obj within the foo() call lifetime as it is now, regardless of any optimizations that the "in" proposal allows, so I don't think that concern should be a show stopper. Either way the results are the same - sporadically incorrect results, and either way it is going to be a bear to debug and proper synchronization by the /user/ of obj and foo() will be the way to fix the problem - same as any other multi-threading issue. I see no problem with just removing the part of the proposal that promises that no other /thread/ will change obj. because I don't think that is practical in any sense at the language implementaton level for a language with the goals of D (D doesn't offer or promise auto-synchronization in any other case, does it?). - Dave
Jul 03 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:da8nqk$161t$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message 
 news:da6k71$11rs$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:da4afr$24jc$1 digitaldaemon.com...
 How would this cover the following case that Walter's proposal covers:
 class A { int x; }
 void foo(in A obj){
   int y = obj.x;
   // do whatever you want...
   assert( obj.x == y );
 }
 void main() {
   A obj = new A;
   foo(obj); // says it doesn't change obj
 }
 Is it practical to force A to implement some immutability just because 
 foo
 doesn't change its inputs? I'm not saying Walter's proposal is prefect.
It's
 very strong for foo to say no other thread or reference will change obj
 since it has no control over what other threads are doing. I would be
taking
 pretty much blind leap of faith when declaring an object reference as 
 'in'
 and saying that no other thread is stepping on that object during the 
 call
 lifetime.
You're right. I have misgivings about it for that reason. On the other hand, look at C++ "const". Nothing about "const" says that some other thread or reference cannot change the value out from under you at any moment. Furthermore, it can be cast away and modified anyway. The semantic value of C++ "const" is essentially zip. This is why I am often flummoxed why it is given such weight in C++.
It is equally probable that another thread could step on obj within the foo() call lifetime as it is now, regardless of any optimizations that the "in" proposal allows, so I don't think that concern should be a show stopper. Either way the results are the same - sporadically incorrect results, and either way it is going to be a bear to debug and proper synchronization by the /user/ of obj and foo() will be the way to fix the problem - same as any other multi-threading issue. I see no problem with just removing the part of the proposal that promises that no other /thread/ will change obj. because I don't think that is practical in any sense at the language implementaton level for a language with the goals of D (D doesn't offer or promise auto-synchronization in any other case, does it?). - Dave
You're right - the threading model shouldn't enter into it. I'm liking Walter's suggestion more now. Earlier I thought it was too strong a condition but now I can see, for example, lots of places in phobos where 'in' can be used.
Jul 03 2005
parent reply "Dave" <Dave_member pathlink.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:da8qa5$17op$1 digitaldaemon.com...
 "Dave" <Dave_member pathlink.com> wrote in message 
 news:da8nqk$161t$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message 
 news:da6k71$11rs$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:da4afr$24jc$1 digitaldaemon.com...
 How would this cover the following case that Walter's proposal covers:
 class A { int x; }
 void foo(in A obj){
   int y = obj.x;
   // do whatever you want...
   assert( obj.x == y );
 }
 void main() {
   A obj = new A;
   foo(obj); // says it doesn't change obj
 }
 Is it practical to force A to implement some immutability just because 
 foo
 doesn't change its inputs? I'm not saying Walter's proposal is prefect.
It's
 very strong for foo to say no other thread or reference will change obj
 since it has no control over what other threads are doing. I would be
taking
 pretty much blind leap of faith when declaring an object reference as 
 'in'
 and saying that no other thread is stepping on that object during the 
 call
 lifetime.
You're right. I have misgivings about it for that reason. On the other hand, look at C++ "const". Nothing about "const" says that some other thread or reference cannot change the value out from under you at any moment. Furthermore, it can be cast away and modified anyway. The semantic value of C++ "const" is essentially zip. This is why I am often flummoxed why it is given such weight in C++.
It is equally probable that another thread could step on obj within the foo() call lifetime as it is now, regardless of any optimizations that the "in" proposal allows, so I don't think that concern should be a show stopper. Either way the results are the same - sporadically incorrect results, and either way it is going to be a bear to debug and proper synchronization by the /user/ of obj and foo() will be the way to fix the problem - same as any other multi-threading issue. I see no problem with just removing the part of the proposal that promises that no other /thread/ will change obj. because I don't think that is practical in any sense at the language implementaton level for a language with the goals of D (D doesn't offer or promise auto-synchronization in any other case, does it?). - Dave
You're right - the threading model shouldn't enter into it. I'm liking Walter's suggestion more now. Earlier I thought it was too strong a condition but now I can see, for example, lots of places in phobos where 'in' can be used.
I think Walter's idea is a great idea and a good compromise! Truth be told, I actually think the following would be the best: [none]/in/out/inout - [none] and 'in' would follow the new proposal with regard to 'immutable', and /all/ would allow the new opimizations that I think Walter has in mind. The exceptions would be pointer params. and functions declared extern or exported, which would simply operate as they do now, where the expectation is that they are treated differently anyway. volatile/volatile in/volatile out/volatile inout - 'volatile', 'volatile in', 'volatile out' and 'volatile inout' params. would basically operate exactly as they do now. Just like other statements in any other scope, a "volatile" param. would mean "inhibit optimizations on the variable that may effect memory reads/writes". Not even a new keyword.. The whole justification for these new defaults is because the cases where "volatile" would have to be used for the code to operate correctly are a small minority, so shouldn't the default go with what benefits the great majority of cases? Also, the same justification goes for making the default [none] and 'in' operate the same way w.r.t. the new proposal - majority of cases rules. Another big plus would be not having to litter code with 'in' (like C++ code is littered with 'const').
Jul 03 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Dave" <Dave_member pathlink.com> wrote in message 
news:da931u$1fto$1 digitaldaemon.com...
 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
 news:da8qa5$17op$1 digitaldaemon.com...
 "Dave" <Dave_member pathlink.com> wrote in message 
 news:da8nqk$161t$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message 
 news:da6k71$11rs$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message
 news:da4afr$24jc$1 digitaldaemon.com...
 How would this cover the following case that Walter's proposal covers:
 class A { int x; }
 void foo(in A obj){
   int y = obj.x;
   // do whatever you want...
   assert( obj.x == y );
 }
 void main() {
   A obj = new A;
   foo(obj); // says it doesn't change obj
 }
 Is it practical to force A to implement some immutability just because 
 foo
 doesn't change its inputs? I'm not saying Walter's proposal is 
 prefect.
It's
 very strong for foo to say no other thread or reference will change 
 obj
 since it has no control over what other threads are doing. I would be
taking
 pretty much blind leap of faith when declaring an object reference as 
 'in'
 and saying that no other thread is stepping on that object during the 
 call
 lifetime.
You're right. I have misgivings about it for that reason. On the other hand, look at C++ "const". Nothing about "const" says that some other thread or reference cannot change the value out from under you at any moment. Furthermore, it can be cast away and modified anyway. The semantic value of C++ "const" is essentially zip. This is why I am often flummoxed why it is given such weight in C++.
It is equally probable that another thread could step on obj within the foo() call lifetime as it is now, regardless of any optimizations that the "in" proposal allows, so I don't think that concern should be a show stopper. Either way the results are the same - sporadically incorrect results, and either way it is going to be a bear to debug and proper synchronization by the /user/ of obj and foo() will be the way to fix the problem - same as any other multi-threading issue. I see no problem with just removing the part of the proposal that promises that no other /thread/ will change obj. because I don't think that is practical in any sense at the language implementaton level for a language with the goals of D (D doesn't offer or promise auto-synchronization in any other case, does it?). - Dave
You're right - the threading model shouldn't enter into it. I'm liking Walter's suggestion more now. Earlier I thought it was too strong a condition but now I can see, for example, lots of places in phobos where 'in' can be used.
I think Walter's idea is a great idea and a good compromise! Truth be told, I actually think the following would be the best: [none]/in/out/inout - [none] and 'in' would follow the new proposal with regard to 'immutable', and /all/ would allow the new opimizations that I think Walter has in mind. The exceptions would be pointer params. and functions declared extern or exported, which would simply operate as they do now, where the expectation is that they are treated differently anyway.
1) How in will solve this: class Record { Field[] fields() { return m_fields.dup; // this is not needed, isn't it? // but it must be here in current D. } } 2) 'In' does not allow to distinguish cases: void toUpper(in char[] str_in_place); char[] toUpper(in const char[] str); and select optimal implementation.
 volatile/volatile in/volatile out/volatile inout - 'volatile', 'volatile 
 in', 'volatile out' and 'volatile inout' params. would basically operate 
 exactly as they do now. Just like other statements in any other scope, a 
 "volatile" param. would mean "inhibit optimizations on the variable that 
 may effect memory reads/writes". Not even a new keyword..

 The whole justification for these new defaults is because the cases where 
 "volatile" would have to be used for the code to operate correctly are a 
 small minority, so shouldn't the default go with what benefits the great 
 majority of cases?

 Also, the same justification goes for making the default [none] and 'in' 
 operate the same way w.r.t. the new proposal - majority of cases rules. 
 Another big plus would be not having to litter code with 'in' (like C++ 
 code is littered with 'const').
"littered with 'const'".... well, it depends.... If European will see Stone Garden in Japan he will find it littered by stones. For me personally code which is not using const looks non-prefessional and written by young hacker in 'fire-n-forget' mode. Non maintainable, non reliable, non optimized. Someone can tell that: private int something1 public int something2 is littered with private and public. Does it *really* mean that it is littered? Andrew.
Jul 03 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:da95gq$1j4t$1 digitaldaemon.com...
 1) How in will solve this:

 class Record
 {
     Field[] fields()
     {
         return m_fields.dup; // this is not needed, isn't it?
                                      // but it must be here in current D.
     }
 }
It won't, but then again, I don't see that the .dup is necessary there, as fields() is a producer of a value, not a consumer.
 2) 'In' does not allow to distinguish cases:

 void toUpper(in char[] str_in_place);
 char[] toUpper(in const char[] str);

 and select optimal implementation.
That's correct, there would be no overloading based on const-ness. I know this is commonplace in C++, but frankly I think it's poor design. A function overloaded on const implicitly has significantly different behavior, and so should have a different name.
 volatile/volatile in/volatile out/volatile inout - 'volatile', 'volatile
 in', 'volatile out' and 'volatile inout' params. would basically operate
 exactly as they do now. Just like other statements in any other scope, a
 "volatile" param. would mean "inhibit optimizations on the variable that
 may effect memory reads/writes". Not even a new keyword..

 The whole justification for these new defaults is because the cases
where
 "volatile" would have to be used for the code to operate correctly are a
 small minority, so shouldn't the default go with what benefits the great
 majority of cases?

 Also, the same justification goes for making the default [none] and 'in'
 operate the same way w.r.t. the new proposal - majority of cases rules.
 Another big plus would be not having to litter code with 'in' (like C++
 code is littered with 'const').
"littered with 'const'".... well, it depends.... If European will see Stone Garden in Japan he will find it littered by stones. For me personally code which is not using const looks non-prefessional and written by young hacker in 'fire-n-forget' mode. Non maintainable, non reliable, non optimized. Someone can tell that: private int something1 public int something2 is littered with private and public. Does it *really* mean that it is littered?
The idea is that the most common case should be the default. Would you agree that for the vast majority of function parameters, they are read only? That mutable ones are relatively rare? If so, then it makes sense to have the uncommon ones need the extra syntax. As for myself, since most parameters in C++ code are const, the const everywhere tends to visually clutter up the code, obscuring the other stuff.
Jul 03 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 2) 'In' does not allow to distinguish cases:

 void toUpper(in char[] str_in_place);
 char[] toUpper(in const char[] str);

 and select optimal implementation.
That's correct, there would be no overloading based on const-ness. I know this is commonplace in C++, but frankly I think it's poor design. A function overloaded on const implicitly has significantly different behavior, and so should have a different name.
Perhaps dstyle.html should say functions with a leading 'to' should not modify their inputs. There are several toFoo functions in phobos and it would be nice to keep that style consistent.
Jul 03 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message
news:da9b6j$1ouo$1 digitaldaemon.com...
 Perhaps dstyle.html should say functions with a leading 'to' should not
 modify their inputs. There are several toFoo functions in phobos and it
 would be nice to keep that style consistent.
That's a good idea. There are also the 'is' prefix functions.
Jul 03 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da9dc2$1r5s$2 digitaldaemon.com...
 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:da9b6j$1ouo$1 digitaldaemon.com...
 Perhaps dstyle.html should say functions with a leading 'to' should not
 modify their inputs. There are several toFoo functions in phobos and it
 would be nice to keep that style consistent.
That's a good idea. There are also the 'is' prefix functions.
I beleive that next will be a proposal to use 'c' as a first char of parameter name and all this will end up with Polish Notation and the like... Poor man type system to be short. Gentlemen, array and immutable slice are two *distinct* types with their own set of operations. The same for pointers - immutable pointer cannot be dereferenced to l-value. And please don't cover holes in type system by inventing naming conventions. This is not honest. Andrew.
Jul 03 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
news:da9k9n$2201$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message 
 news:da9dc2$1r5s$2 digitaldaemon.com...
 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:da9b6j$1ouo$1 digitaldaemon.com...
 Perhaps dstyle.html should say functions with a leading 'to' should not
 modify their inputs. There are several toFoo functions in phobos and it
 would be nice to keep that style consistent.
That's a good idea. There are also the 'is' prefix functions.
I beleive that next will be a proposal to use 'c' as a first char of parameter name and all this will end up with Polish Notation and the like... Poor man type system to be short. Gentlemen, array and immutable slice are two *distinct* types with their own set of operations. The same for pointers - immutable pointer cannot be dereferenced to l-value. And please don't cover holes in type system by inventing naming conventions. This is not honest. Andrew.
Nothing is preventing someone from writing void upper(char[] str); char[] toUpper(char[] str); I see no reason to abuse the already-established conventions with the "to" prefix. Multiple versions of toUpper might seem natural to you and your team but it isn't "typical" D code. Even if all your proposals were accepted I would still argue a function named toUpper should not modify its input. That isn't saying your general point is wrong - just that the example you gave using the name "toUpper" isn't one that should be encouraged.
Jul 03 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote in message 
news:da9lak$23de$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message 
 news:da9k9n$2201$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message 
 news:da9dc2$1r5s$2 digitaldaemon.com...
 "Ben Hinkle" <ben.hinkle gmail.com> wrote in message
 news:da9b6j$1ouo$1 digitaldaemon.com...
 Perhaps dstyle.html should say functions with a leading 'to' should not
 modify their inputs. There are several toFoo functions in phobos and it
 would be nice to keep that style consistent.
That's a good idea. There are also the 'is' prefix functions.
I beleive that next will be a proposal to use 'c' as a first char of parameter name and all this will end up with Polish Notation and the like... Poor man type system to be short. Gentlemen, array and immutable slice are two *distinct* types with their own set of operations. The same for pointers - immutable pointer cannot be dereferenced to l-value. And please don't cover holes in type system by inventing naming conventions. This is not honest. Andrew.
Nothing is preventing someone from writing void upper(char[] str); char[] toUpper(char[] str); I see no reason to abuse the already-established conventions with the "to" prefix. Multiple versions of toUpper might seem natural to you and your team but it isn't "typical" D code. Even if all your proposals were accepted I would still argue a function named toUpper should not modify its input. That isn't saying your general point is wrong - just that the example you gave using the name "toUpper" isn't one that should be encouraged.
Ben, am I propsing to abuse naming conventions? No. 'to' works in some places and for someone - fine. But how this related to const? OT: this 'to' in Russian is one letter and sometimes looks funny combined with camelCase.
Jul 03 2005
parent Victor Nakoryakov <nail-mail mail.ru> writes:
Andrew Fedoniouk wrote:
 
 OT: this 'to' in Russian is one letter and sometimes looks funny combined
 with camelCase.
 
Emmmm... All speaking russian use english for variables/methods/classes as well as in comments. So this is no matter how such things are translated to native language, you will never find constructions ala stroka kStroke(); :) -- Victor (aka nail) Nakoryakov nail-mail<at>mail<dot>ru Krasnoznamensk, Moscow, Russia
Jul 04 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da99t5$1net$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da95gq$1j4t$1 digitaldaemon.com...
 1) How in will solve this:

 class Record
 {
     Field[] fields()
     {
         return m_fields.dup; // this is not needed, isn't it?
                                      // but it must be here in current D.
     }
 }
It won't, but then again, I don't see that the .dup is necessary there, as fields() is a producer of a value, not a consumer.
 2) 'In' does not allow to distinguish cases:

 void toUpper(in char[] str_in_place);
 char[] toUpper(in const char[] str);

 and select optimal implementation.
That's correct, there would be no overloading based on const-ness. I know this is commonplace in C++, but frankly I think it's poor design. A function overloaded on const implicitly has significantly different behavior, and so should have a different name.
 volatile/volatile in/volatile out/volatile inout - 'volatile', 
 'volatile
 in', 'volatile out' and 'volatile inout' params. would basically 
 operate
 exactly as they do now. Just like other statements in any other scope, 
 a
 "volatile" param. would mean "inhibit optimizations on the variable 
 that
 may effect memory reads/writes". Not even a new keyword..

 The whole justification for these new defaults is because the cases
where
 "volatile" would have to be used for the code to operate correctly are 
 a
 small minority, so shouldn't the default go with what benefits the 
 great
 majority of cases?

 Also, the same justification goes for making the default [none] and 
 'in'
 operate the same way w.r.t. the new proposal - majority of cases rules.
 Another big plus would be not having to litter code with 'in' (like C++
 code is littered with 'const').
"littered with 'const'".... well, it depends.... If European will see Stone Garden in Japan he will find it littered by stones. For me personally code which is not using const looks non-prefessional and written by young hacker in 'fire-n-forget' mode. Non maintainable, non reliable, non optimized. Someone can tell that: private int something1 public int something2 is littered with private and public. Does it *really* mean that it is littered?
The idea is that the most common case should be the default. Would you agree that for the vast majority of function parameters, they are read only? That mutable ones are relatively rare? If so, then it makes sense to have the uncommon ones need the extra syntax.
Walter, imagine that you know nothing about internals of this function: char* toStringz(char[] string) what you can tell about it? And if you'll see char[] toStringz(const char[] string) isn't it better? You don't need documentation or its source code in most cases.
 As for myself, since most parameters in C++ code are const, the const
 everywhere tends to visually clutter up the code, obscuring the other 
 stuff.
most cases are strings I believe. So do alias const char[] string; alias char[] string_buffer; and use this strings. Word 'string' has same number of characters as 'char[]'. And forget about clutter.
Jul 03 2005
parent "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:da9jf7$210d$1 digitaldaemon.com...
 most cases are strings I believe. So do
I'm afraid not. Take a look at the STL source code :-( Go into \dm\stlport\stlport\stl and do a grep for "const".
Jul 03 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:da99t5$1net$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:da95gq$1j4t$1 digitaldaemon.com...
 1) How in will solve this:

 class Record
 {
     Field[] fields()
     {
         return m_fields.dup; // this is not needed, isn't it?
                                      // but it must be here in current D.
     }
 }
It won't, but then again, I don't see that the .dup is necessary there, as fields() is a producer of a value, not a consumer.
 2) 'In' does not allow to distinguish cases:

 void toUpper(in char[] str_in_place);
 char[] toUpper(in const char[] str);

 and select optimal implementation.
That's correct, there would be no overloading based on const-ness. I know this is commonplace in C++, but frankly I think it's poor design. A function overloaded on const implicitly has significantly different behavior, and so should have a different name.
1 ) There are situations when you just cannot use different names. E.g. template specializations. 2) "overloaded on const implicitly has significantly different behavior" This apply also to all cases of function overloading. E.g. foo(int i) and foo(char[] s) might have a significantly different behavior, isn't it? 3) "should have a different name" - someone will consider D as language forcing "name pollution" then. Following this statement all toString() shall be rewritten as toStringFromXXX( XXX x );
 volatile/volatile in/volatile out/volatile inout - 'volatile', 
 'volatile
 in', 'volatile out' and 'volatile inout' params. would basically 
 operate
 exactly as they do now. Just like other statements in any other scope, 
 a
 "volatile" param. would mean "inhibit optimizations on the variable 
 that
 may effect memory reads/writes". Not even a new keyword..

 The whole justification for these new defaults is because the cases
where
 "volatile" would have to be used for the code to operate correctly are 
 a
 small minority, so shouldn't the default go with what benefits the 
 great
 majority of cases?

 Also, the same justification goes for making the default [none] and 
 'in'
 operate the same way w.r.t. the new proposal - majority of cases rules.
 Another big plus would be not having to litter code with 'in' (like C++
 code is littered with 'const').
"littered with 'const'".... well, it depends.... If European will see Stone Garden in Japan he will find it littered by stones. For me personally code which is not using const looks non-prefessional and written by young hacker in 'fire-n-forget' mode. Non maintainable, non reliable, non optimized. Someone can tell that: private int something1 public int something2 is littered with private and public. Does it *really* mean that it is littered?
The idea is that the most common case should be the default. Would you agree that for the vast majority of function parameters, they are read only? That mutable ones are relatively rare? If so, then it makes sense to have the uncommon ones need the extra syntax. As for myself, since most parameters in C++ code are const, the const everywhere tends to visually clutter up the code, obscuring the other stuff.
Yep, as I meantioned above: alias const char[] string; will help.
Jul 03 2005