I found critical bug.

string d = "a"~"b"~(1?"a":"");

>Error: Can only concatenate arrays, not (char[] ~ invariant(char)[])
then compiler hangs up.

Walter Bright wrote:
> This is an alpha release to try out the const/final/invariant stuff.
> 
> The current definition of string is:
> 
>     alias const(char)[] string;
> 
> Andrei has argued strongly to make it invariant. I think he's probably right, and that change might happen next.

Out of curiosity, is this at all meaningful?

void fn( inout string val ) {}


Sean

Sean Kelly wrote:
> Walter Bright wrote:
>> This is an alpha release to try out the const/final/invariant stuff.
>>
>> The current definition of string is:
>>
>>     alias const(char)[] string;
>>
>> Andrei has argued strongly to make it invariant. I think he's probably right, and that change might happen next.
> 
> Out of curiosity, is this at all meaningful?
> 
> void fn( inout string val ) {}

Sure. (assuming you fill in the {}s)
That definition of the string alias only makes the contents of the string const, not the reference to it. So you're free to assign the array reference passed in to some other string (including slices of the initial value).
This will still hold if the contents become invariant, by the way.

Seems to me that D is going into the wrong direction.
Are you really sure that strings should be inmutable by default?
Not in my world. In my world an invariant string is the *Exeption*.

I hate that feature because it s nature is /pessimistic/ and says "Do not trust the programmer".

So please tell me what do we have to expect from D 2 ?
More CPP like programming refined with syntactic sugar,or something that makes D comparable to Java s useablility ?
Bjoern



Walter Bright schrieb:
> This is an alpha release to try out the const/final/invariant stuff.
> 
> The current definition of string is:
> 
>     alias const(char)[] string;
> 
> Andrei has argued strongly to make it invariant. I think he's probably right, and that change might happen next.
> 
> The documentation isn't thorough, I don't want to spend too much time on it until I'm sure we've got the design right.
> 
> Treat this as an alpha release. Although it passes its test suite, I'm sure there are plenty of bugs remaining. Phobos also has not been thoroughly gone through to put const/final in all the right places.
> 
> See http://www.digitalmars.com/d/final-const-invariant.html
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.2.000.zip
> 
> Expect changes to this. Much more to come! For stability, I recommend sticking with the 1.0 series, which I will maintain with bug fixes.

Walter Bright wrote:
> The current definition of string is:
> 
> alias const(char)[] string;
> 
> Andrei has argued strongly to make it invariant. I think he's probably right, and that change might happen next.

I don't think invariant here is such a great idea, consider the following function.

void foo(string s){}

if string is const this can be called with both char[] and const(char)[] (if
not please correct me) but if my understanding is correct char[] would not
work if string is invariant. This will lead to an unessesary amount of
cast(invariant) when calling functions on local strings (as functions that
create strings will have to modify the when they are being built).

Johan Granberg wrote:
> I don't think invariant here is such a great idea, consider the following
> function.
> 
> void foo(string s){}
> 
> if string is const this can be called with both char[] and const(char)[] (if
> not please correct me) but if my understanding is correct char[] would not
> work if string is invariant. This will lead to an unessesary amount of
> cast(invariant) when calling functions on local strings (as functions that
> create strings will have to modify the when they are being built).

That's essentially my argument against it, too. The other side is that treating strings as if they are value types is common and effective in other languages. (For example, strings in Perl are invariant.)

One of the reasons for adding .idup is to reduce the need to cast to invariant.

BLS wrote:
> Seems to me that D is going into the wrong direction.
> Are you really sure that strings should be inmutable by default?
> Not in my world. In my world an invariant string is the *Exeption*.

String literals have always been immutable. The string alias is just that, an alias. You can still use char[] if you prefer, which would be mutable strings.

> I hate that feature because it s nature is /pessimistic/ and says "Do not trust the programmer".

The motivating factor for const is that as program complexity increases, being able to put more of the specification of an interface into the code itself (rather than relying on the documentation) will increase the reliability of the system.

The trust the programmer part in D comes from there being an escape from the typing system (in the form of the cast).

> So please tell me what do we have to expect from D 2 ?
> More CPP like programming refined with syntactic sugar,or something that makes D comparable to Java s useablility ?

Java has no escape from its typing system.

On Mon, 18 Jun 2007 14:41:28 +0300, Alexander Panek <a.panek@brainsware.org> wrote:

> sambeau wrote:
>> </lurk>
>>
>> Just a small thought.
>> 'invariant' just looks un-'C'-like.
>> We are happy with int and const..
>> Could I propose 'inv' (as well) to save fingers?
>>
>> <lurk>
>
> I don't agree. This is D 2.0 after all, not the successor to C/C++ alone, anymore.

Indeed. Further down that path, and we'll start suggesting symbols instead of keywords, and end up with something like Perl or an esoteric language.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow@gmail.com

Thank you for taking the time to explain. It would be nice if you can add  this information to the D homepage "Rationale section". I guess I am not the only one who needs this /lesson/ <g>
Thanks again, Bjoern

Walter Bright schrieb:
> BLS wrote:
>> Seems to me that D is going into the wrong direction.
>> Are you really sure that strings should be inmutable by default?
>> Not in my world. In my world an invariant string is the *Exeption*.
> 
> String literals have always been immutable. The string alias is just that, an alias. You can still use char[] if you prefer, which would be mutable strings.
> 
>> I hate that feature because it s nature is /pessimistic/ and says "Do not trust the programmer".
> 
> The motivating factor for const is that as program complexity increases, being able to put more of the specification of an interface into the code itself (rather than relying on the documentation) will increase the reliability of the system.
> 
> The trust the programmer part in D comes from there being an escape from the typing system (in the form of the cast).
> 
>> So please tell me what do we have to expect from D 2 ?
>> More CPP like programming refined with syntactic sugar,or something that makes D comparable to Java s useablility ?
> 
> Java has no escape from its typing system.

This looks great!

But as it is, I can't find a difference between invariant(char)[] and invariant(char[]). For both of them:

    invariant(char[]) a; // or for invariant(char)[] a
    a = "foo";  // works
//    a[0] = 'a'; // fails
    a = a[1..$]; // works

And, unless I'm missing something, it seems like there's a problem with aliases:

    void main()
    {
       alias invariant(Foo) T;
       T s = T(new int);
       *s.a = 5;
    }

    struct Foo
    {
        int* a;
    }

the above code compiles, although it wouldn't if I skipped the alias.

And thirdly, I'm not sure about invariant and const as storage classes. They seem to be identical, saying "a compile-time constant", but also applying transitively to their types. But if I have a compile-time constant, how can it refer to data that can change?

It also feels odd to me, since we seem to have two storage classes to effectively say the same thing: "known at compile-time, doesn't occupy space." Am I right? Would this mean (except for not wanting to add yet *more* keywords) that this is an orthogonal notion which could perhaps warrant *yet* *another* term?


It's been lots of fun to play with, though. Thanks!


  -- Reiner