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.

Just wanted to say congratulations on getting this out; it's like Christmas six months early :)

Now, if you'll excuse me, I have to go and play with the new compiler...

	-- Daniel

Walter Bright wrote:
> This is an alpha release to try out the const/final/invariant stuff.

Earlier than expected! Congratulations!

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

It might be a good idea if you'd post the minutes of your meetings with Andrei. The community got irritated (grain of salt, please) when it had the feeling D got designed behind its back, and that was when Andrei was frequently posting!

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

Small thing:
int* q = const_castp; // ok
Seems that the < and > aren't escaped?

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

I especially enjoy string/wstring/dstring, believe it or not.. :)

Thanks for this.

L.

So, I *finally* understand why those parens are there for const and invariant: I didn't realise they were usable as storage classes now!

But this brings up a question: if "in" is the same as "scope const final", does this mean the "final" is redundant?  I mean, you can't reassign to a const storage variable anyway.  The only other effect of final, allowing you to assign to members in a constructor, doesn't really seem like it would apply to function arguments.

Also, it appears that TypeInfos aren't printing the parens around composite types; should they?

writefln("const char[]:  %s", typeid(const char[]));
writefln("const(char)[]: %s", typeid(const(char)[]));

Produces:

const char[]:  const const char[]
const(char)[]: const char[]

	-- Daniel

Walter Bright wrote:
> This is an alpha release to try out the const/final/invariant stuff.

Very nice, thanks! Some questions:

Should extern (C) functions with const parameters now include the const? I notice you've added "in" to the C functions in Phobos, is that more correct?

Should the main function now take some const form of the command line arguments?

Will structs get constructors, as a struct seems to have under "Final Storage Class"?

What's the difference between const and invariant member functions? The example under "Invariant Member Functions" behaves the same whether it's invariant or const.

> Expect changes to this. Much more to come!

I'm waiting eagerly.

-- 
Remove ".doesnotlike.spam" from the mail address.

Deewiant wrote:
> Should extern (C) functions with const parameters now include the const? I
> notice you've added "in" to the C functions in Phobos, is that more correct?

Yes.

> Should the main function now take some const form of the command line arguments?

Yes.

> Will structs get constructors, as a struct seems to have under "Final Storage
> Class"?

Yes.

> What's the difference between const and invariant member functions? The example
> under "Invariant Member Functions" behaves the same whether it's invariant or const.

const means that the member function cannot change the instance. Invariant means nobody can change the instance.

Walter Bright wrote:
> Deewiant wrote:
>> Should the main function now take some const form of the command line arguments?
> 
> Yes.

The documentation (under "Functions") still states:
=====
main() must be declared using one of the following forms:

void main() { ... }
void main(char[][] args) { ... }
int main() { ... }
int main(char[][] args) { ... }
=====
You may want to update that if const and invariant versions of the parameter are now allowed (and perhaps any variants with the new string alias in there as well :) ).

</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>

W00t! Great job, Walter :D


/* it looks like some html pages are missing from dmd/html. e.g. final-const-invariant.html or the whole 1.0 dir */


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

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.