www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 2.000 alpha release

reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Jun 17 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Jun 17 2007
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Jun 18 2007
prev sibling next sibling parent Lionello Lunesu <lio lunesu.remove.com> writes:
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.
Jun 18 2007
prev sibling next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
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.
Jun 18 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Jun 18 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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 :) ).
Jun 18 2007
prev sibling next sibling parent reply sambeau <spam_sambeau mac.com> writes:
</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>
Jun 18 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
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.
Jun 18 2007
parent "Vladimir Panteleev" <thecybershadow gmail.com> writes:
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
Jun 18 2007
prev sibling next sibling parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
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
Jun 18 2007
prev sibling next sibling parent nazo <lovesyao gmail.com> writes:
I found critical bug.

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


Error: Can only concatenate arrays, not (char[] ~ invariant(char)[])
Jun 18 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Jun 18 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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.
Jun 18 2007
prev sibling next sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
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.
Jun 18 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Jun 18 2007
parent BLS <nanali nospam-wanadoo.fr> writes:
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.
Jun 19 2007
prev sibling parent reply davidl <davidl 126.com> writes:
In my world , nature is pessimistic and says "Do not trust the programmer"

Programmers even those top hackers could still make silly bugs , and  
several
other top hackers will spend dozens times effort on fixing it.

In my opinion , the language itself should be as much pessimistic as  
possible.
This could squeeze out the every possibilies of making mistakes by some  
error-
compromising compilers.


 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.








-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Jun 20 2007
parent 0ffh <spam frankhirsch.net> writes:
davidl wrote:

 In my world , nature is pessimistic and says "Do not trust the programmer"



Poor sod... :)

I my world, if you cannot trust the programmer, you can trust no one.

Regards, Frank

---

First they have forbidden typecasts, then they have abolished true pointers,
now everyone is coding in Java......
Jun 20 2007
prev sibling next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
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).
Jun 18 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Jun 18 2007
parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
Walter Bright wrote:

 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.



I realize that string is, at it's base, an alias.  But 
thinking of string as a type, if string is a const, then there 
ought to be a word to allow the declaration of non-const strings.

I.e., if a type that is not inherently const is made const by 
the language, then there ought to be a modifier to remove the 
const'ness of it.  This is clumsy, so perhaps strings should 
not be const.

As for the way that other languages do things... I seem to 
recall that the justification for implementing const strings 
has usually been speed.  Would that apply in the case of D?

So my argument against const strings is basically shaped 
around symmetry.  If symmetry is broken by having strings be 
const, then to restore it one would need a type modifier 
meaning mutable

The potential argument in favor of const strings seems, to me, 
to be speed.  But I don't know whether it applies.
Jun 19 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Charles D Hixson wrote:

 The potential argument in favor of const strings seems, to me, to be 
 speed.  But I don't know whether it applies.



The argument for const strings isn't speed, it's understandability. 
People tend to think of them as value types (like ints), and by making 
strings const (or invariant) it makes them behave like value types.
Jun 20 2007
parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Wed, 20 Jun 2007 19:55:47 -0700, Walter Bright wrote:


 Charles D Hixson wrote:

 The potential argument in favor of const strings seems, to me, to be 
 speed.  But I don't know whether it applies.



 The argument for const strings isn't speed, it's understandability. 



I thought it was about safety. About not accidentally changing stuff that
was not indented to be changed.


 People tend to think of them as value types (like ints),



No problems with that so far ...


  and by making 
 strings const (or invariant) it makes them behave like value types.



This is where you lose me though. Your statement seems to only apply when
talking about function parameters -- and then it really is about speed too.

For example, I can get the same effect as const even when not using const,
but at a run-time cost.

Without CONST
   void func(char[] a) { ... }
   char str = "abc".dup;
   func(str.dup); // Now I don't care what 'func' does with my data.

With CONST
   void func(const (char)[] a) { ... }
   char str = "abc".dup;
   func(str); // I still don't care what 'func' does with my data.

The difference is that the CONST version is faster and gives the compiler a
clue about the writer's intentions (and thus can issue appropriate error
messages)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
21/06/2007 2:00:38 PM
Jun 20 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Derek Parnell wrote:

 On Wed, 20 Jun 2007 19:55:47 -0700, Walter Bright wrote:
 

 Charles D Hixson wrote:

 The potential argument in favor of const strings seems, to me, to be 
 speed.  But I don't know whether it applies.






 I thought it was about safety. About not accidentally changing stuff that
 was not indented to be changed.



The two are closely related.



  and by making 
 strings const (or invariant) it makes them behave like value types.



 This is where you lose me though. Your statement seems to only apply when
 talking about function parameters -- and then it really is about speed too.
 
 For example, I can get the same effect as const even when not using const,
 but at a run-time cost.
 
 Without CONST
    void func(char[] a) { ... }
    char str = "abc".dup;
    func(str.dup); // Now I don't care what 'func' does with my data.
 
 With CONST
    void func(const (char)[] a) { ... }
    char str = "abc".dup;
    func(str); // I still don't care what 'func' does with my data.
 
 The difference is that the CONST version is faster and gives the compiler a
 clue about the writer's intentions (and thus can issue appropriate error
 messages)



Value types work by making lots of copies. By making a reference type 
const, it can behave as a value type without the cost of making copies. 
In that context, yes, it is about speed.
Jun 21 2007
prev sibling next sibling parent reply Reiner Pope <some address.com> writes:
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
Jun 19 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Reiner Pope wrote:

 This looks great!
 
 But as it is, I can't find a difference between invariant(char)[] and 
 invariant(char[]).



There isn't one for declarations, as the const/invariant doesn't apply 
to the declaration's value itself - only what the declaration refers to.



 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?



There is no difference between:

	const int x = 3;

and:

	invariant int x = 3;

The difference between const and invariant shows up with references to 
other data.
Jun 20 2007
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Great, thank you!
Jun 19 2007
prev sibling next sibling parent reply Jascha Wetzel <firstname mainia.de> writes:
considering the 3 declarations
1) const(char)* p;
2) const(char*) p;
3) const char*  p;

i identify 3 entities in play here: the character *p, the address of 
it's memory cell p and the location where that address is stored &p. the 
language let's us change p and *p, &p is always invariant.
in 3) p and *p are const,
in 2) p is mutable and *p is const
and 1) is the same!?

what is const in 2) that is mutable in 1) ?
Jun 20 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Jascha Wetzel wrote:

 considering the 3 declarations
 1) const(char)* p;
 2) const(char*) p;
 3) const char*  p;
 
 i identify 3 entities in play here: the character *p, the address of 
 it's memory cell p and the location where that address is stored &p. the 
 language let's us change p and *p, &p is always invariant.
 in 3) p and *p are const,
 in 2) p is mutable and *p is const
 and 1) is the same!?
 
 what is const in 2) that is mutable in 1) ?



In this case, there is no difference between (1) and (2), because a 
const type for a declaration's value is ignored.

For (3), const is being used as a storage class, not a type modifier, 
and so p is not mutable.
Jun 20 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:

 
 See http://www.digitalmars.com/d/final-const-invariant.html
 



This html file is not present in dmd.2.000.zip .



-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 23 2007