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)[])


then compiler hangs up.
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.


 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.


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 Pablo Ripolles <in-call gmx.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.)


And in Python too!
Jun 19 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 MicroWizard <microwizard_no_spam_ at_ax_dot.hu> writes:
Walter!

I have been following the evolution of D for at least five years.
Nowadays all of my personal projects are written in D. No exception.
Seeing D 1.00 was great in January. After it 1.013 (maybe 014) with struct
literals was the last thing I ever needed from D.

BUT: This 2.000 and it's 'features' looks like your are joking.
Stop it! Bullshit! Const string is the worst thing I ever heard.

D is great dealing char arrays, slicing, COW and soon. Let it so.

If you have no idea what to do, please wait! No need to hurry!


MicroShit developers WILL NOT use D even it supports const.

I do not want to hurt You, Walter or anyone reading this news.
I only want to warn the community. This is a mistake. Bad direction.

Regards,
Tams Nagy
Hungary


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.
 
 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 19 2007
next sibling parent reply mandel <mandel mailinator.com> writes:
MicroWizard Wrote:


 BUT: This 2.000 and it's 'features' looks like your are joking.
 Stop it! Bullshit! Const string is the worst thing I ever heard.


Harsh words.
If you don't bring forward arguments,
your post will most likely be ignored.
Jun 19 2007
parent Dejan Lekic <dejan.lekic gmail.com> writes:
It is already ignored in my case, because this guy obviously did not follow
thorogh discussion about matters he criticizes...
Jun 19 2007
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
MicroWizard wrote:

 Walter!
 
 I have been following the evolution of D for at least five years.
 Nowadays all of my personal projects are written in D. No exception.
 Seeing D 1.00 was great in January. After it 1.013 (maybe 014) with struct
literals was the last thing I ever needed from D.
 
 BUT: This 2.000 and it's 'features' looks like your are joking.
 Stop it! Bullshit! Const string is the worst thing I ever heard.
 
 D is great dealing char arrays, slicing, COW and soon. Let it so.
 
 If you have no idea what to do, please wait! No need to hurry!
 

 MicroShit developers WILL NOT use D even it supports const.
 
 I do not want to hurt You, Walter or anyone reading this news.
 I only want to warn the community. This is a mistake. Bad direction.
 
 Regards,
 Tams Nagy
 Hungary
 


You are kidding, right?  I've been specifically sitting on all my 
projects, twiddling my thumbs, just waiting /for/ the new 
final|const|invariant!  Now I'm just waiting for Tango to go D/2.0 and I 
can get down to serious work again (finally).  This is going to save me 
plenty of memory costs (imagine, no longer .dup'ing lots of strings and 
other arrays just to play it safe against silly end users modifying what 
they shouldn't) not to mention debugging headaches.

Yes... clearly you must be kidding.

-- Chris Nicholson-Sauls
Jun 19 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 20 Jun 2007 01:25:23 +0400, Chris Nicholson-Sauls  
<ibisbasenji gmail.com> wrote:


 I've been specifically sitting on all my projects, twiddling my thumbs,  
 just waiting /for/ the new final|const|invariant!  Now I'm just waiting  
 for Tango to go D/2.0 and I can get down to serious work again (finally).


<old-talk>
Some time ago I waited for D 1.0. Now I'm awaiting D 2.0. Then, I'm  
afraid, I would wait for next major stable version of D. There ins't any  
sign that after almost seven years of development D will became stable and  
mature language.

Excuse me for repeating that.
</old-talk>


 This is going to save me plenty of memory costs (imagine, no longer  
 .dup'ing lots of strings and other arrays just to play it safe against  
 silly end users modifying what they shouldn't) not to mention debugging  
 headaches.


How do you plain to reduce count of .dup's in D 2.0?

-- 
Regards,
Yauheni Akhotnikau
Jun 20 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
eao197 wrote:

 <old-talk>
 Some time ago I waited for D 1.0. Now I'm awaiting D 2.0. Then, I'm
 afraid, I would wait for next major stable version of D. There ins't any
 sign that after almost seven years of development D will became stable
 and mature language.
 
 Excuse me for repeating that.
 </old-talk>


So use D 1.0--it's stable now!  As Walter has said, it's just going to
be maintained with bugfixes now, no more moving target.

If your argument is "I can't use D 1.0 because D 2.0 exists", then I
suspect you won't be happy until D has ceased all evolution and updates,
effectively dying, at which point you'll probably start using a
different, shinier language.

Sometimes you've just got to draw a line in the sand and not step across
it.  The game I'm currently writing will, despite how much I want to use
D 2.0, be written in D 1.0 because it's now a fixed target, and has
libraries and tools working with it.  Yes, it's tearing me up inside not
having shiny new const, but getting the game written and working is more
important to me right now.


 This is going to save me plenty of memory costs (imagine, no longer
 .dup'ing lots of strings and other arrays just to play it safe against
 silly end users modifying what they shouldn't) not to mention
 debugging headaches.


 
 How do you plain to reduce count of .dup's in D 2.0?


I believe what Chris is talking about is that if you want an array (or
any other reference type, for that matter) that is absolutely guaranteed
not to change on you, you currently need to .dup the whole thing every
single time.

With D 2.0, it will be possible to overload functions to accept an
invariant reference, which we don't need to dup, making the code more
efficient.

	-- Daniel
Jun 20 2007
parent eao197 <eao197 intervale.ru> writes:
On Wed, 20 Jun 2007 14:19:47 +0400, Daniel Keep  
<daniel.keep.lists gmail.com> wrote:


 eao197 wrote:

 <old-talk>
 Some time ago I waited for D 1.0. Now I'm awaiting D 2.0. Then, I'm
 afraid, I would wait for next major stable version of D. There ins't any
 sign that after almost seven years of development D will became stable
 and mature language.

 Excuse me for repeating that.
 </old-talk>


 So use D 1.0--it's stable now!  As Walter has said, it's just going to
 be maintained with bugfixes now, no more moving target.

 If your argument is "I can't use D 1.0 because D 2.0 exists", then I
 suspect you won't be happy until D has ceased all evolution and updates,
 effectively dying, at which point you'll probably start using a
 different, shinier language.


It is not easy to me to start use different language because I have big  
enough rather old code which I should maintain and advance. At best I will  
be able to maintain old C++ code and write new code in D.

<old-talk-again>
In my option the problem with branching D into 1.0 and 2.0 not in  
language. The problem in the libraries, tools, documetation and people  
around D.

For example, now D is attracting new people. Someone want to write new  
tools/libraries for D. Which version will they choose? Stable, but old, D  
1.0 or unstable, but very promising and attractive D 2.0? I'm affraid many  
of them choose D 2.0 (because I would do that). And because of that in  
time D 2.0 would have more tools/libraries than D 1.0.

The same thing with documentation. The same thing with teaching people to  
program in D. Even worse. Designing programs without consts/invariants is  
much different than designing programs with consts/invariants. So why to  
spend time to teaching new programmers to use old-style D instead of  
teaching them new-style D?

I like to see consts/invariants in D. But... Implantaion of D as main  
programming language (instead of C++, like in my case) in industry needs a  
lot of efforts to re-teaching people, creating some proof-of-concent  
projects, defining some corporate politics and best practices. Even in the  
best conditions it may took months, may be years. Why to make thing ever  
worse with language which is always in beta-stage?

I need to remember that in addition to early adopters (like you, Daniel)  
and technologist (like I) there are many, many rather conservative,  
pessimistic and simply lazy programmers who don't want to study something  
new every month or even a half-year. But they do much, much work. Please  
keep them in mind.

Excuse me for repeating that yet more time.
</old-talk-again>

-- 
Regards,
Yauheni Akhotnikau
Jun 20 2007
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
eao197 wrote:

 On Wed, 20 Jun 2007 01:25:23 +0400, Chris Nicholson-Sauls 
 <ibisbasenji gmail.com> wrote:
 

 I've been specifically sitting on all my projects, twiddling my 
 thumbs, just waiting /for/ the new final|const|invariant!  Now I'm 
 just waiting for Tango to go D/2.0 and I can get down to serious work 
 again (finally).


 
 <old-talk>
 Some time ago I waited for D 1.0. Now I'm awaiting D 2.0. Then, I'm 
 afraid, I would wait for next major stable version of D. There ins't any 
 sign that after almost seven years of development D will became stable 
 and mature language.
 
 Excuse me for repeating that.
 </old-talk>


You are excused, especially since I've played the same waiting game 
(indeed).  That said, I'm probably going to just ride the 2.0 branch at 
this point and be happy.  I'll refactor if and when anything 
just-too-nifty comes along.


 This is going to save me plenty of memory costs (imagine, no longer 
 .dup'ing lots of strings and other arrays just to play it safe against 
 silly end users modifying what they shouldn't) not to mention 
 debugging headaches.


 
 How do you plain to reduce count of .dup's in D 2.0?
 


By returning const views rather than copies.  Or in some cases, 
referances to invariant data.

-- Chris Nicholson-Sauls
Jun 20 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 20 Jun 2007 17:39:43 +0400, Chris Nicholson-Sauls  =

<ibisbasenji gmail.com> wrote:


 This is going to save me plenty of memory costs (imagine, no longer =






 =


 .dup'ing lots of strings and other arrays just to play it safe again=






st  =


 silly end users modifying what they shouldn't) not to mention  =







 debugging headaches.


  How do you plain to reduce count of .dup's in D 2.0?


 By returning const views rather than copies.  Or in some cases,  =



 referances to invariant data.


Do you mean something like:

class Demo
   {
     this( const char * name )
       {
         name_ =3D name.dup;
       }

     const char *
     getName() { return name_; }

   private:
     char[] name_;
   }

instead of

   char[]
   getName() { return name_.dup; }

?

-- =

Regards,
Yauheni Akhotnikau
Jun 20 2007
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
eao197 wrote:

 On Wed, 20 Jun 2007 17:39:43 +0400, Chris Nicholson-Sauls 
 <ibisbasenji gmail.com> wrote:
 

 This is going to save me plenty of memory costs (imagine, no longer 
 .dup'ing lots of strings and other arrays just to play it safe 
 against silly end users modifying what they shouldn't) not to 
 mention debugging headaches.


  How do you plain to reduce count of .dup's in D 2.0?


 By returning const views rather than copies.  Or in some cases, 
 referances to invariant data.


 
 Do you mean something like:
 
 class Demo
   {
     this( const char * name )
       {
         name_ = name.dup;
       }
 
     const char *
     getName() { return name_; }
 
   private:
     char[] name_;
   }
 
 instead of
 
   char[]
   getName() { return name_.dup; }
 
 ?
 


Rough draft off the top of my head, working from an actual project:



































Usage:
auto alpha = BSymbol["test"] ;
auto beta  = BSymbol["test"] ;
assert(alpha is beta);

(The use of this isn't obvious I know.  Just trust me that it has great 
utility in the program its part of.)

Now first, yes, there are two .idup's in there.  I'm not sure if they're 
neccessary or not, and haven't tested things yet.  But... in the 
original, there are /three/ .dup's.  I can now do away with the one in 
.string(), which is the one I'm most worried about, since the duplicate 
it would've created is short-lived.  (The other two are very long-lived; 
life of the program, in theory.)  Thus, having those 'invariant's in 
there lets me avoid a myriad of needless copies -- I can just copy it on 
the user side if I need to, most likley happening automatically as part 
of a concatenation.

Now I just need to a chance to test this to see if it all works in the 
way my head seems to have it organized.

-- Chris Nicholson-Sauls
Jun 20 2007
prev sibling parent davidl <davidl 126.com> writes:
You say something is bad, while without any suggestions. How can we know
there *is* something better than the current design? For me, I can only
assume you just kidding, and you actually don't know any better solutions.


 Walter!

 I have been following the evolution of D for at least five years.
 Nowadays all of my personal projects are written in D. No exception.
 Seeing D 1.00 was great in January. After it 1.013 (maybe 014) with  
 struct literals was the last thing I ever needed from D.

 BUT: This 2.000 and it's 'features' looks like your are joking.
 Stop it! Bullshit! Const string is the worst thing I ever heard.

 D is great dealing char arrays, slicing, COW and soon. Let it so.

 If you have no idea what to do, please wait! No need to hurry!


 MicroShit developers WILL NOT use D even it supports const.

 I do not want to hurt You, Walter or anyone reading this news.
 I only want to warn the community. This is a mistake. Bad direction.

 Regards,
 Tamás Nagy
 Hungary


 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.

 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
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 next 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
prev sibling parent =?ISO-8859-1?Q?Lu=eds_Marques?= <luismarques+spam gmail.com> writes:
About "Removing Invariant With A Cast", it says:

"The ability to cast away invariant-correctness is necessary in some cases
where the static typing is incorrect and not fixable, such as when referencing
code in a library one cannot change. Casting is, as always, a blunt and
effective instrument, and when using it to cast away invariant-correctness, one
must assume the responsibility to ensure the invariantness of the data, as the
compiler will no longer be able to statically do so."

Given that it is (implicitly) stated that 1) removing invariant is a rare
occasion and 2) that it carries a large danger, have you considered making it a
two step process:

invariant int* p = ...;
int* q = cast(int*) cast(void*) p;

It would be similar to the process where you statically cast an object by first
casting it to void*. When casting by mistake from an invariant the compiler
could warn you, but that would still be overridable with the cast to void.
Jun 25 2007