On Tue, 28 Apr 2009 23:39:14 +0000 (UTC), BCS wrote:

> Reply to Derek,
> 
>> What has surprised me is that immutability is *not* guaranteed.


> The language has asm blocks can can call C. The only things it can guarantee are the same things the OS can guarantee.

Oh, I agree. It is just that the documentation is pretty adamant that "immutability" means that the data WILL NOT change. It gives the impression that there is compiler support to ensure that this is axiomatic rather than just a convention.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Paul D. Anderson:
> From the D2.0/Language/Functions page, under Function Parameters:
> "The in storage class is equivalent to const scope."
> That's why the "const in" combination doesn't work.

Why is this working then, and printing 100?

import std.stdio: writeln;
void foo(const ref int x) {
    writeln(x * 10);
}
void main() {
    int y = 10;
    foo(y);
}

Note that the following doesn't compile:
void foo(in ref int x) {

Bye,
bearophile

Derek Parnell wrote:
> On Tue, 28 Apr 2009 23:39:14 +0000 (UTC), BCS wrote:
> 
>> Reply to Derek,
>>
>>> What has surprised me is that immutability is *not* guaranteed.
> 
>  
>> The language has asm blocks can can call C. The only things it can guarantee are the same things the OS can guarantee.
> 
> Oh, I agree. It is just that the documentation is pretty adamant that
> "immutability" means that the data WILL NOT change. It gives the impression
> that there is compiler support to ensure that this is axiomatic rather than
> just a convention.
> 

IMHO it's more than a convention.

Andrei

Derek Parnell wrote:
> On Tue, 28 Apr 2009 23:39:14 +0000 (UTC), BCS wrote:
> 
>> Reply to Derek,
>>
>>> What has surprised me is that immutability is *not* guaranteed.
> 
>  
>> The language has asm blocks can can call C. The only things it can guarantee are the same things the OS can guarantee.
> 
> Oh, I agree. It is just that the documentation is pretty adamant that
> "immutability" means that the data WILL NOT change. It gives the impression
> that there is compiler support to ensure that this is axiomatic rather than
> just a convention.

It's supposed to give the impression that if you DO change it, undefined behavior (including crashes, if the value was stored in ROM) could result.

Derek Parnell wrote:
> Oh, I agree. It is just that the documentation is pretty adamant that
> "immutability" means that the data WILL NOT change. It gives the impression
> that there is compiler support to ensure that this is axiomatic rather than
> just a convention.

D is a systems programming language. By that I mean that there are mechanisms to defeat the type system, for those that know what they're doing.

If you defeat the type system, and mutate immutably-typed data, the onus is on you. It's like if you pop the carburetor off and put a supercharger on, you void the warranty <g>.

bearophile wrote:
> Paul D. Anderson:
>> From the D2.0/Language/Functions page, under Function Parameters:
>> "The in storage class is equivalent to const scope."
>> That's why the "const in" combination doesn't work.
> 
> Why is this working then, and printing 100?
> 
> import std.stdio: writeln;
> void foo(const ref int x) {
>     writeln(x * 10);
> }

You are not changig x here. The x*10 just multiplies and returns its result to writeln.

> void main() {
>     int y = 10;
>     foo(y);
> }
> 
> Note that the following doesn't compile:
> void foo(in ref int x) {
> 
> Bye,
> bearophile

On Wed, 29 Apr 2009 03:35:32 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Derek Parnell wrote:
>> Oh, I agree. It is just that the documentation is pretty adamant that
>> "immutability" means that the data WILL NOT change. It gives the impression
>> that there is compiler support to ensure that this is axiomatic rather than
>> just a convention.
>
> D is a systems programming language. By that I mean that there are mechanisms to defeat the type system, for those that know what they're doing.
>
> If you defeat the type system, and mutate immutably-typed data, the onus is on you. It's like if you pop the carburetor off and put a supercharger on, you void the warranty <g>.

I hate having to keep argue this, but you keep forgetting.  You cannot create immutable data without circumventing the type system (except strings which have special treatment).

Only way to make an immutable class:

auto c = cast(immutable(C))new C;

You have just circumvented the type system, and it's on you as a programmer to guarantee that C's constructor didn't store mutable references to itself somewhere, NOT the compiler.

Until this is fixed, immutability is far less useful (except for strings).

It's like you are buying a car where the dealer says you void the warranty if you put gas in it.

-Steve

Steven Schveighoffer wrote:
> On Wed, 29 Apr 2009 03:35:32 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
> 
>> Derek Parnell wrote:
>>> Oh, I agree. It is just that the documentation is pretty adamant that
>>> "immutability" means that the data WILL NOT change. It gives the impression
>>> that there is compiler support to ensure that this is axiomatic rather than
>>> just a convention.
>>
>> D is a systems programming language. By that I mean that there are mechanisms to defeat the type system, for those that know what they're doing.
>>
>> If you defeat the type system, and mutate immutably-typed data, the onus is on you. It's like if you pop the carburetor off and put a supercharger on, you void the warranty <g>.
> 
> I hate having to keep argue this, but you keep forgetting.  You cannot create immutable data without circumventing the type system (except strings which have special treatment).

Yes, this is a bug, and one not easy to fix (requires a bit of flow control in constructors), but we know how to fix it. It's just a matter of time.

Andrei