"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.

typename #[]
typename #*

Please pay attention that there is no whitespace between # and [ Here # is not a shortcut for const !  It is part of #[] declaration.

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; }

}

Then #[] - immutable array type will be (internally) declared as:

primitive "#[ ]" (T)
{
   private T #*_ptr;
   private uint _length;

   T #* ptr() { return _ptr; }

   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 :
   void opAssign(struct "#[ ]" (T) r)  { _ptr = r._ptr; _length =
r._length; }
}

As you may see implementation of #[] is pretty straightforward and simple. 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.

If you will implement #[] and #* then type system will be complete (almost
perfect) -
*all* D types will have an option to be immutable.

Andrew.

>> 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.
>
> typename #[]
> typename #*
>
> Please pay attention that there is no whitespace between # and [ Here # is not a shortcut for const !  It is part of #[] declaration.

Why is the lack of whitespace between the # and the [ significant?

> Let's say that D array type internally declared as
[snip]
> As you may see implementation of #[] is pretty straightforward and 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.

> 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.
>
> If you will implement #[] and #* then type system will be complete (almost
> perfect) -
> *all* D types will have an option to be immutable.
>
> Andrew.

"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.

foo( in char#[] str )  means that str will not be changed after return and as by definition of immutable array content pointed by str.ptr will not be changed.

foo( in char#[] str )
foo( inout char#[] str )
foo( out char#[] str )

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.

One more: as char[] and char#[] are friendly but distinct types thus they allow you and compiler to distinguish cases:

foo( char#[] str )
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.
>>
>> typename #[]
>> typename #*
>>
>> Please pay attention that there is no whitespace between # and [ Here # is not a shortcut for const !  It is part of #[] declaration.
>
> Why is the lack of whitespace between the # and the [ significant?

Because '#' is not a keyword like const as it is part of lexical sequence:
#[].   In short #[ and #* accepted as one symbol by lexer making
'#' free to use for other purposes.
Pretty much as '+ =' and '+='


>
>> Let's say that D array type internally declared as
> [snip]
>> As you may see implementation of #[] is pretty straightforward and 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.
For statics char#[] makes perfect sense.
If only typename#[] variables can have static initializers - this will
significantly simplify life and make D clear. Now it is just sequence of
"why's" - why it allowed here and not there.

Considering Harmonia switch to use of char#[] :
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.
>>
>> If you will implement #[] and #* then type system will be complete
>> (almost perfect) -
>> *all* D types will have an option to be immutable.
>>
>> Andrew.
>
> 

"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++.

"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" :-)
It's funny that Java and C# don't have const and people seem to survive.
Granted in Java people IMO overcompensate by dup'ing too often so I hope D
users don't go that route.

"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" :-)
> It's funny that Java and C# don't have const and people seem to survive.
> Granted in Java people IMO overcompensate by dup'ing too often so I hope D
> users don't go that route.

"Java and C# don't have const"

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.

C# has 'readonly' keyword. It can be used in declaration of class fields and
in declaration of function parameters.
C# has also const keyword which is pretty much D keyword except of C#::const
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).

Only char#[] and char[] *together* can be considered as "string in D" by C++, Java or C# programmers.

"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.

One more:

Java, C#, C, C++ and Pascal (Delphi)
has concept of const (parameters and references)
and these are the most popular languages so far.

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...
>
>"Java and C# don't have const"
>
>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.
>
>C# has 'readonly' keyword. It can be used in declaration of class fields and
>in declaration of function parameters.
>C# has also const keyword which is pretty much D keyword except of C#::const
>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).
>
>Only char#[] and char[] *together* can be considered as "string in D" by C++, Java or C# programmers.
>

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").

"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" :-)
>> It's funny that Java and C# don't have const and people seem to survive.
>> Granted in Java people IMO overcompensate by dup'ing too often so I hope
>> D users don't go that route.
>
> "Java and C# don't have const"
>
> 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.

> C# has 'readonly' keyword. It can be used in declaration of class fields
> and in declaration of function parameters.
> C# has also const keyword which is pretty much D keyword except of
> C#::const is protecting also references. E.g. you cannot
> say "hello"[0] = 'b';

Sure, but this, too, isn't const. D has getters and setters so one can make readonly properties. I know about C#'s const vaguely but I'm not sure what you mean by "is protecting also references". The example you give is of a string but strings are immutable and are independent of C#'s const keyword 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!

Immutable strings is really the only place where D diverges from Java/C#. 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).
>
> Only char#[] and char[] *together* can be considered as "string in D" by C++, Java or C# programmers.

Why bother with multiple types/classes when D already spanks the competition with one? We should keep things as simple as possible.