www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 0.174 release

reply Walter Bright <newshound digitalmars.com> writes:
Much improved tuple support.

New 'scope' attribute for RAII objects. 'auto' still works the same, but 
will not for much longer. Use 'auto' for type inference.

http://www.digitalmars.com/d/changelog.html

http://ftp.digitalmars.com/dmd.174.zip
Nov 14 2006
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
This is a great release, thank you!
Nov 14 2006
prev sibling next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
Documentation for http://www.digitalmars.com/d/declaration.html#AutoDeclaration needs to be updated to reflect the changes to RAII. I couldnt find any updates to the spec grammar either.
Nov 14 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Kyle Furlong wrote:
 Walter Bright wrote:
 Much improved tuple support.

 New 'scope' attribute for RAII objects. 'auto' still works the same, 
 but will not for much longer. Use 'auto' for type inference.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.174.zip
Documentation for http://www.digitalmars.com/d/declaration.html#AutoDeclaration needs to be updated to reflect the changes to RAII. I couldnt find any updates to the spec grammar either.
http://www.digitalmars.com/d/attribute.html#scope was updated, seems the above page is the only one in need of an update.
Nov 14 2006
prev sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Kyle Furlong wrote:
 Walter Bright wrote:
 Much improved tuple support.

 New 'scope' attribute for RAII objects. 'auto' still works the same, 
 but will not for much longer. Use 'auto' for type inference.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.174.zip
Documentation for http://www.digitalmars.com/d/declaration.html#AutoDeclaration needs to be updated to reflect the changes to RAII. I couldnt find any updates to the spec grammar either.
In http://www.digitalmars.com/d/template.html, "A Tuple whose elements consist entirely of types is called a TypeTuple. A Tuple whose elements consist entirely of types is called an ExpressionTuple." should read such that the last line is "...consist entirely of expressions...."
Nov 14 2006
parent Walter Bright <newshound digitalmars.com> writes:
I folded in the changes, thanks.
Nov 14 2006
prev sibling next sibling parent reply "JohnC" <johnch_atms hotmail.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ejdj7u$da3$1 digitaldaemon.com...
 Much improved tuple support.
Very cool. One area where type tuples don't work is in place of a base class list. Any chance of supporting this usage? template ImplementsCore(T ...) { ... } abstract class Implements(T ...) : T[0 .. $] { mixin ImplementsCore!(T); }
Nov 14 2006
parent Walter Bright <newshound digitalmars.com> writes:
JohnC wrote:
 One area where type tuples don't work is in place of a base class list. Any 
 chance of supporting this usage?
 
 template ImplementsCore(T ...) {
   ...
 }
 
 abstract class Implements(T ...) : T[0 .. $] {
   mixin ImplementsCore!(T);
 } 
I never thought of that. I'll see if it can be done.
Nov 14 2006
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
"Improved the statement grammar thanks to Stewart Gordon." Good work on the whole. However, I'm puzzled by a few issues: 1. At first sight it appears to bear little resemblance to my rewrite. OK, so it implements the distinction between things that introduce a new scope and things that don't, and on closer examination you've taken into account some of the other issues I've raised. But what's happened to the issue of where a DeclarationStatement or ScopeGuardStatement (fka ScopeStatement) should be legal? Moving DeclarationStatement and ScopeGuardStatement from NonEmptyStatement into Statement, NoScopeNonEmptyStatement and NoScopeStatement would achieve the same as my version in this respect. 2. You haven't done the necessary updates to http://www.digitalmars.com/d/version.html 3. You've added ; as a Statement form. You still haven't told us what the language gains by having it. OK, so having it in NoScopeStatement simplifies specifying PragmaStatement and LabeledStatement, which are the only things that use it, but in Statement it appears to serve no purpose. 4. Why do ForStatement and ForeachStatement now take a NoScopeNonEmptyStatement as body, rather than a ScopeStatement? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Nov 14 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 Good work on the whole.  However, I'm puzzled by a few issues:
 
 1. At first sight it appears to bear little resemblance to my rewrite. 
 OK, so it implements the distinction between things that introduce a new 
 scope and things that don't, and on closer examination you've taken into 
 account some of the other issues I've raised.  But what's happened to 
 the issue of where a DeclarationStatement or ScopeGuardStatement (fka 
 ScopeStatement) should be legal?
 
 Moving DeclarationStatement and ScopeGuardStatement from 
 NonEmptyStatement into Statement, NoScopeNonEmptyStatement and 
 NoScopeStatement would achieve the same as my version in this respect.
What I did was carefully go through the parse code, and adjust the grammar to exactly match it. So while we can argue about what it should be, at least for the moment it matches what the compiler actually does.
 2. You haven't done the necessary updates to
 
 http://www.digitalmars.com/d/version.html
I know, lazy me <g>.
 3. You've added
 
     ;
 
 as a Statement form.  You still haven't told us what the language gains 
 by having it.  OK, so having it in NoScopeStatement simplifies 
 specifying PragmaStatement and LabeledStatement, which are the only 
 things that use it, but in Statement it appears to serve no purpose.
It can also appear in case statements and default statements.
 4. Why do ForStatement and ForeachStatement now take a 
 NoScopeNonEmptyStatement as body, rather than a ScopeStatement?
The scope is created by the for initialization, not the body.
Nov 14 2006
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
Walter Bright escribió:
 Stewart Gordon wrote:
 Good work on the whole.  However, I'm puzzled by a few issues:

 1. At first sight it appears to bear little resemblance to my rewrite. 
 OK, so it implements the distinction between things that introduce a 
 new scope and things that don't, and on closer examination you've 
 taken into account some of the other issues I've raised.  But what's 
 happened to the issue of where a DeclarationStatement or 
 ScopeGuardStatement (fka ScopeStatement) should be legal?

 Moving DeclarationStatement and ScopeGuardStatement from 
 NonEmptyStatement into Statement, NoScopeNonEmptyStatement and 
 NoScopeStatement would achieve the same as my version in this respect.
What I did was carefully go through the parse code, and adjust the grammar to exactly match it. So while we can argue about what it should be, at least for the moment it matches what the compiler actually does.
In the DMD code a DeclarationStatement can hold a lot of kinds of declarations, not just variables. For example this is valid: void bla() { class X { } // DeclarationStatement holding an AggregateDeclaration } However in the spec says "Declaration statements declare and initialize variables". Should the spec be corrected? The first time I saw it I thought there was no possible way to declare a class inside a function. This holds true for enums, too.
Nov 15 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Ary Manzana wrote:
 However in the spec says "Declaration statements declare and initialize 
 variables". Should the spec be corrected?
It already has been <g>.
Nov 15 2006
parent Ary Manzana <ary esperanto.org.ar> writes:
Walter Bright escribió:
 Ary Manzana wrote:
 However in the spec says "Declaration statements declare and 
 initialize variables". Should the spec be corrected?
It already has been <g>.
How powerful is ctrl+F5 in Firefox... Realy! (sorry)
Nov 15 2006
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
<snip>
 4. Why do ForStatement and ForeachStatement now take a 
 NoScopeNonEmptyStatement as body, rather than a ScopeStatement?
The scope is created by the for initialization, not the body.
So the whole ForStatement creates a scope, and Initialize, Test, Increment and the statement body all share this scope? This ought to be a little clearer. The way it's written at the moment ("that variable's scope extends through the end of NoScopeNonEmptyStatement") looks like a contradiction. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Nov 16 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 So the whole ForStatement creates a scope, and Initialize, Test, 
 Increment and the statement body all share this scope?
Yes.
 This ought to be 
 a little clearer.  The way it's written at the moment ("that variable's 
 scope extends through the end of NoScopeNonEmptyStatement") looks like a 
 contradiction.
Good point.
Nov 16 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
 So the whole ForStatement creates a scope, and Initialize, Test, 
 Increment and the statement body all share this scope?
Yes.
 This ought to be a little clearer.  The way it's written at the moment 
 ("that variable's scope extends through the end of 
 NoScopeNonEmptyStatement") looks like a contradiction.
Good point.
Moreover, this whole way of putting things can lead one to wonder whether variables declared in the body are reinitialized each iteration.... Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Nov 16 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 Moreover, this whole way of putting things can lead one to wonder 
 whether variables declared in the body are reinitialized each iteration....
Why? A declaration is just like an assignment statement. It is executed when it appears. If it appears in a loop, it is executed each iteration of that loop.
Nov 16 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
 Moreover, this whole way of putting things can lead one to wonder 
 whether variables declared in the body are reinitialized each 
 iteration....
Why? A declaration is just like an assignment statement. It is executed when it appears. If it appears in a loop, it is executed each iteration of that loop.
True in general, but.... - in general, a declaration such as int x; doesn't look like an assignment statement - the idea of the same variable being declared multiple times in the same instance of being in the same scope is alien to many - there are also static local variables, which aren't reset each time Moreover, your claim that the _body_ of a for loop doesn't create a scope would also mean that ScopeGuardStatements and scope (fka auto) object references within the body are not processed at the end of each iteration, but saved until the end of the whole for loop. Absolutely not the behaviour I'm experiencing. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Nov 17 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 Stewart Gordon wrote:
 Moreover, this whole way of putting things can lead one to wonder 
 whether variables declared in the body are reinitialized each 
 iteration....
Why? A declaration is just like an assignment statement. It is executed when it appears. If it appears in a loop, it is executed each iteration of that loop.
True in general, but.... - in general, a declaration such as int x; doesn't look like an assignment statement
Since D has default assignment in declarations, it is one. It behaves the same way in C++ (for types that have default constructors). D isn't doing anything weird here.
 - the idea of the same variable being declared multiple times in the 
 same instance of being in the same scope is alien to many
? You cannot declare the same variable multiple times in the same scope.
 - there are also static local variables, which aren't reset each time
Again, this behaves just like C++, and should not be surprising.
 Moreover, your claim that the _body_ of a for loop doesn't create a 
 scope would also mean that ScopeGuardStatements and scope (fka auto) 
 object references within the body are not processed at the end of each 
 iteration, but saved until the end of the whole for loop.  Absolutely 
 not the behaviour I'm experiencing.
The for statement itself generates a scope, not the { }. This behaves exactly like the for statement in C++.
Nov 17 2006
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
<snip>
 - the idea of the same variable being declared multiple times in the 
 same instance of being in the same scope is alien to many
? You cannot declare the same variable multiple times in the same scope.
What I meant is that, in order for the count variable to continue across iterations, it would imply that the control enters and leaves the scope only once for the whole for loop. And so for (int x = 0; x < 3; x++) { int y = x*x; writefln(y); } would seem equivalent to { int x = 0; int y0 = x * x; writefln(y0); x++; int y1 = x * x; writefln(y1); x++; int y2 = x * x; writefln(y2); x++; } i.e. in each instance a new y is declared, hiding the previous, but they don't go out of scope till the end of the loop. OK, so there's also the goto, which could be used to go back to before a declaration statement and execute it again. JTAI, I suppose that explains something. You're not really redeclaring it, but merely resetting its value. So while declarations may be anywhere within a function, at the internal level the placement of a declaration is merely the point at which the variable is given its initial value.
 - there are also static local variables, which aren't reset each time
Again, this behaves just like C++, and should not be surprising.
 Moreover, your claim that the _body_ of a for loop doesn't create a 
 scope would also mean that ScopeGuardStatements and scope (fka auto) 
 object references within the body are not processed at the end of each 
 iteration, but saved until the end of the whole for loop.  Absolutely 
 not the behaviour I'm experiencing.
The for statement itself generates a scope, not the { }. This behaves exactly like the for statement in C++.
Does the flow of control enter and leave this scope only once for the whole for loop or once for each iteration? - If once for the whole loop, how would you explain the behaviour of scope guards that I'm experiencing? - If for each iteration, then how does the counter variable (if declared in the Initialize) keep hold of its value between iterations? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Nov 17 2006
parent Walter Bright <newshound digitalmars.com> writes:
Oops, you're right, it was misbehaving. I'll get it fixed.
Nov 18 2006
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Stewart Gordon wrote:
<snip>
 3. You've added

     ;

 as a Statement form.  You still haven't told us what the language 
 gains by having it.  OK, so having it in NoScopeStatement simplifies 
 specifying PragmaStatement and LabeledStatement, which are the only 
 things that use it, but in Statement it appears to serve no purpose.
It can also appear in case statements and default statements.
<snip> Shouldn't these just be special cases of LabeledStatement? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Nov 19 2006
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 Stewart Gordon wrote:
<snip>
 3. You've added

     ;

 as a Statement form.  You still haven't told us what the language 
 gains by having it.  OK, so having it in NoScopeStatement simplifies 
 specifying PragmaStatement and LabeledStatement, which are the only 
 things that use it, but in Statement it appears to serve no purpose.
It can also appear in case statements and default statements.
<snip> Shouldn't these just be special cases of LabeledStatement?
Two possible solutions: LabeledStatement: Label ':' NoScopeStatement Label: Identifier 'case' ExpressionList 'default' (replacing CaseStatement and DefaultStatement) or LabeledStatement: Identifier ':' NoScopeStatement CaseStatement: 'case' ExpressionList ':' NoScopeStatement DefaultStatement: 'default' ':' NoScopeStatement _Please_ make up your mind whether it's LabeledStatement or LabelledStatement! BTW the links to CaseStatement and DefaultStatement on statement.html are broken. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Nov 19 2006
prev sibling next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
You know what's awesome? This works now: http://paste.dprogramming.com/dpbaqugv.php That code is a sort of rough breakdown of how Pyd's function wrapping support works. It's actually /understandable/ now. -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.org
Nov 14 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Kirk McDonald wrote:
 You know what's awesome? This works now:
 http://paste.dprogramming.com/dpbaqugv.php
 
 That code is a sort of rough breakdown of how Pyd's function wrapping 
 support works. It's actually /understandable/ now.
Some chapters of "Modern C++ Design" now shrink to a single page!
Nov 14 2006
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Kirk McDonald" <kirklin.mcdonald gmail.com> wrote in message 
news:ejdvqp$pnk$1 digitaldaemon.com...

 You know what's awesome? This works now:
 http://paste.dprogramming.com/dpbaqugv.php

 That code is a sort of rough breakdown of how Pyd's function wrapping 
 support works. It's actually /understandable/ now.
Oh. My. I am so excited about what I'll be able to do with MiniD's binding lib now.
Nov 14 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Nice work!  It's good to see the old cruft being cleaned out, and the 
vararg templates are finally pretty usable :-)


Sean
Nov 14 2006
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
And The Bright One did look down upon his Creation after many days and saw that all was Not Right, for though he had been clear of mind and spirit during the Creation, it had changed and must be fixed. Thus did he come down amongst the people living within his Creation, and listened to their cries and the Wailing and Gnashing of Teeth, and did come upon the means with which to return to the purity of his Vision. And then as ascending once more to his place in the heavens, he did say "Let it be so." And with much satisfaction did he see the peoples rejoice, and the world become that much more ordered. -- Book of D, chapter 11 verse 15. Although, come to think of it, this probably applies to most D releases. Hope you're getting frequent flyer points for all this ascending/descending :P Incidentally, I don't suppose we've got a large enough body of pseudo-religious text to make a parody of The Book of Mozilla, do we? :P -- Daniel -- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Nov 14 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
Daniel Keep wrote:
 Walter Bright wrote:
 Much improved tuple support.

 New 'scope' attribute for RAII objects. 'auto' still works the same, but
 will not for much longer. Use 'auto' for type inference.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.174.zip
And The Bright One did look down upon his Creation after many days and saw that all was Not Right, for though he had been clear of mind and spirit during the Creation, it had changed and must be fixed. Thus did he come down amongst the people living within his Creation, and listened to their cries and the Wailing and Gnashing of Teeth, and did come upon the means with which to return to the purity of his Vision. And then as ascending once more to his place in the heavens, he did say "Let it be so." And with much satisfaction did he see the peoples rejoice, and the world become that much more ordered. -- Book of D, chapter 11 verse 15. Although, come to think of it, this probably applies to most D releases. Hope you're getting frequent flyer points for all this ascending/descending :P Incidentally, I don't suppose we've got a large enough body of pseudo-religious text to make a parody of The Book of Mozilla, do we? :P -- Daniel
I LOL'd.
Nov 14 2006
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:ejdj7u$da3$1 digitaldaemon.com...
 Much improved tuple support.

 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.174.zip
What a great release. Thank you so much. On a side note, this marks my 100th D update since I found D at 0.74!
Nov 14 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:eje966$1184$1 digitaldaemon.com...
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:ejdj7u$da3$1 digitaldaemon.com...
 Much improved tuple support.

 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.

 http://www.digitalmars.com/d/changelog.html

 http://ftp.digitalmars.com/dmd.174.zip
A few questions: 1) For the delegate .funcptr property, would it be possible for it to include the context pointer as the first parameter? Currently the .funcptr allows us to get the type / call signature of the delegate but it's not possible to actually use the resulting function as there is no way to pass it the context short of dipping into ASM.. 2) The class/struct .tupleof property is cool, but is there any way to get at the names of the corresponding fields? Additionally, what would _really_ rock my socks would be a way to get the tuple of the class/struct _methods_. That would probably immediately make many kinds of reflection possible from within the language. Indexing tuples rules, btw.
Nov 14 2006
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Jarrett Billingsley wrote:
 A few questions:
 
 1) For the delegate .funcptr property, would it be possible for it to 
 include the context pointer as the first parameter?  Currently the .funcptr 
 allows us to get the type / call signature of the delegate but it's not 
 possible to actually use the resulting function as there is no way to pass 
 it the context short of dipping into ASM..
 
Not so: Walter added a .ptr property to delegates in 0.168. Between that and .funcptr, you've got all you need to mess with delegates right there. (And, even before these properties, you could hack delegates apart with a union/struct trick. No need to mess with ASM.) -- Kirk McDonald Pyd: Wrapping Python with D http://pyd.dsource.org
Nov 14 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Kirk McDonald" <kirklin.mcdonald gmail.com> wrote in message 
news:ejeepp$15n1$1 digitaldaemon.com...
 Jarrett Billingsley wrote:
 A few questions:

 1) For the delegate .funcptr property, would it be possible for it to 
 include the context pointer as the first parameter?  Currently the 
 .funcptr allows us to get the type / call signature of the delegate but 
 it's not possible to actually use the resulting function as there is no 
 way to pass it the context short of dipping into ASM..
Not so: Walter added a .ptr property to delegates in 0.168. Between that and .funcptr, you've got all you need to mess with delegates right there.
Well even with the context pointer, how do you propose passing it to the resulting func pointer? The context is passed implicitly as the first parameter to any delegate, and without that first parameter in the parameter list, you can't pass the context. So class A { void fork(int x) { } } A a = new A(); auto dg = &a.fork; auto fp = dg.funcptr; fp(3); // access violation What's worse is that because the parameter list doesn't include the context, trying to call fp will result in all the arguments being shifted down a position from where they should be, i.e. 3 will now be in the 'this' slot, and nothing useful will be in the 'x' slot. :S So you _have_ to use ASM to call that func pointer, or maybe use some template trickery to create a pointer to the function with an extra first param.
Nov 15 2006
next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Jarrett Billingsley wrote:
 "Kirk McDonald" <kirklin.mcdonald gmail.com> wrote in message 
 news:ejeepp$15n1$1 digitaldaemon.com...
 Jarrett Billingsley wrote:
 A few questions:

 1) For the delegate .funcptr property, would it be possible for it to 
 include the context pointer as the first parameter?  Currently the 
 .funcptr allows us to get the type / call signature of the delegate but 
 it's not possible to actually use the resulting function as there is no 
 way to pass it the context short of dipping into ASM..
Not so: Walter added a .ptr property to delegates in 0.168. Between that and .funcptr, you've got all you need to mess with delegates right there.
Well even with the context pointer, how do you propose passing it to the resulting func pointer? The context is passed implicitly as the first parameter to any delegate, and without that first parameter in the parameter list, you can't pass the context. So class A { void fork(int x) { } } A a = new A(); auto dg = &a.fork; auto fp = dg.funcptr; fp(3); // access violation What's worse is that because the parameter list doesn't include the context, trying to call fp will result in all the arguments being shifted down a position from where they should be, i.e. 3 will now be in the 'this' slot, and nothing useful will be in the 'x' slot. :S So you _have_ to use ASM to call that func pointer, or maybe use some template trickery to create a pointer to the function with an extra first param.
I spent four months of my spare time getting something like that to work in C++ for all compilers. But this is D. With tuples it's easy, you could even say trivial! R function(void *, U) makeCallable(R, U...)(R delegate(U) dg) { return cast(R function(void *, U))dg.funcptr; }
Nov 15 2006
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Don Clugston wrote:
 I spent four months of my spare time getting something like that to work 
 in C++ for all compilers. But this is D. With tuples it's easy, you 
 could even say trivial!
 
 R function(void *, U) makeCallable(R, U...)(R delegate(U) dg)
 {
     return cast(R function(void *, U))dg.funcptr;
 }
According to http://www.digitalmars.com/d/abi.html , 'this' is passed *last*, not first. So then we get: ---- R function(U, void *) makeCallable(R, U...)(R delegate(U) dg) { return cast(R function(U, void *))dg.funcptr; } ---- As far as I can see, that should work on the following conditions: * The input is not a variadic delegate. * The return value is not a struct. (Except that on Windows it should work for 1,2,4 or 8-byte structs, but not for other sizes) Haven't tested it though, I just thought something was off and checked the ABI ref.
Nov 15 2006
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Frits van Bommel wrote:
 Don Clugston wrote:
 I spent four months of my spare time getting something like that to 
 work in C++ for all compilers. But this is D. With tuples it's easy, 
 you could even say trivial!

 R function(void *, U) makeCallable(R, U...)(R delegate(U) dg)
 {
     return cast(R function(void *, U))dg.funcptr;
 }
According to http://www.digitalmars.com/d/abi.html , 'this' is passed *last*, not first. So then we get: ---- R function(U, void *) makeCallable(R, U...)(R delegate(U) dg) { return cast(R function(U, void *))dg.funcptr; } ---- As far as I can see, that should work on the following conditions: * The input is not a variadic delegate. * The return value is not a struct. (Except that on Windows it should work for 1,2,4 or 8-byte structs, but not for other sizes) Haven't tested it though, I just thought something was off and checked the ABI ref.
I should add another disclaimer: This is based on the section "Function Calling Conventions" of that page. I assumed the calling convention for delegates is equal (with the context pointer replacing the 'this' pointer), which I can't find explicitly mentioned on that page. Though I think it's a logical assumption if you assume it was made as easy as possible to produce delegates from member functions.
Nov 15 2006
prev sibling parent reply Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
Jarrett Billingsley wrote:
 "Kirk McDonald" <kirklin.mcdonald gmail.com> wrote in message 
 news:ejeepp$15n1$1 digitaldaemon.com...
 Jarrett Billingsley wrote:
 A few questions:

 1) For the delegate .funcptr property, would it be possible for it to 
 include the context pointer as the first parameter?  Currently the 
 .funcptr allows us to get the type / call signature of the delegate but 
 it's not possible to actually use the resulting function as there is no 
 way to pass it the context short of dipping into ASM..
Not so: Walter added a .ptr property to delegates in 0.168. Between that and .funcptr, you've got all you need to mess with delegates right there.
Well even with the context pointer, how do you propose passing it to the resulting func pointer? The context is passed implicitly as the first parameter to any delegate, and without that first parameter in the parameter list, you can't pass the context. So class A { void fork(int x) { } } A a = new A(); auto dg = &a.fork; auto fp = dg.funcptr; fp(3); // access violation What's worse is that because the parameter list doesn't include the context, trying to call fp will result in all the arguments being shifted down a position from where they should be, i.e. 3 will now be in the 'this' slot, and nothing useful will be in the 'x' slot. :S So you _have_ to use ASM to call that func pointer, or maybe use some template trickery to create a pointer to the function with an extra first param.
I'm not sure if this is what you want, but here's a cast-free 'call' function: import std.stdio : writefln; class A { int a_m; this(int a) { this.a_m = a; } void fork(int b) { writefln(a_m,b); } } void main() { A a = new A(1); A b = new A(2); auto dg = &a.fork; auto fp = dg.funcptr; call(fp, a, 3); // Prints 13 call(fp, b, 3); // Prints 23 } B call(A, B, Params...)(B function (Params) fp, A a, Params p) { B delegate(Params) dg; dg.funcptr = fp; dg.ptr = a; return dg(p); }
Nov 15 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Reiner Pope" <reiner.pope REMOVE.THIS.gmail.com> wrote in message 
news:ejg8qd$475$1 digitaldaemon.com...
 Jarrett Billingsley wrote:
 I'm not sure if this is what you want, but here's a cast-free 'call' 
 function:

 ...code...
Ah! That's an alright tradeoff. I didn't actually know that you could set the .ptr and .funcptr properties of delegates; I thought they were read-only! Cool.
Nov 15 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Jarrett Billingsley wrote:
 Ah!  That's an alright tradeoff.  I didn't actually know that you could set 
 the .ptr and .funcptr properties of delegates; I thought they were 
 read-only!  Cool. 
I suppose my background in tinkering with cars shows here <g>.
Nov 16 2006
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Jarrett Billingsley wrote:
 "Reiner Pope" <reiner.pope REMOVE.THIS.gmail.com> wrote in message 
 news:ejg8qd$475$1 digitaldaemon.com...
 
Jarrett Billingsley wrote:
I'm not sure if this is what you want, but here's a cast-free 'call' 
function:

...code...
Ah! That's an alright tradeoff. I didn't actually know that you could set the .ptr and .funcptr properties of delegates; I thought they were read-only! Cool.
I didn't know this either... and it opens some ideas up to me... Like, perhaps one could do the following: Might actually be slightly cheaper than a normal call in some cases, particularly of Foo and/or bar() are final. Will have to test it... -- Chris Nicholson-Sauls
Nov 16 2006
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Chris Nicholson-Sauls wrote:
 Jarrett Billingsley wrote:
 
 "Reiner Pope" <reiner.pope REMOVE.THIS.gmail.com> wrote in message 
 news:ejg8qd$475$1 digitaldaemon.com...

 Jarrett Billingsley wrote:
 I'm not sure if this is what you want, but here's a cast-free 'call' 
 function:

 ...code...
Ah! That's an alright tradeoff. I didn't actually know that you could set the .ptr and .funcptr properties of delegates; I thought they were read-only! Cool.
I didn't know this either... and it opens some ideas up to me... Like, perhaps one could do the following: Might actually be slightly cheaper than a normal call in some cases, particularly of Foo and/or bar() are final. Will have to test it... -- Chris Nicholson-Sauls
Well, I tested it. And the results are... pretty neutral, really. Which is a plus in its own right, because it does at least mean one can use this trick without worry. Some exemplar output from the test program: Repeats: 100 Iterations: 1000 List size: 500 Virtual call: 0 sec / 20 msec / 21417 usec Manipulated delegate: 0 sec / 18 msec / 19367 usec Repeats: 100 Iterations: 5000 List size: 500 Virtual call: 0 sec / 86 msec / 87139 usec Manipulated delegate: 0 sec / 86 msec / 86640 usec Repeats: 100 Iterations: 5000 List size: 25 Virtual call: 0 sec / 7 msec / 8117 usec Manipulated delegate: 0 sec / 6 msec / 6901 usec So, yes, there is occasionally some speedup from using the manipulated delegate, but its nothing to scream about. And it appears that, as the size of the data increases, or the number of iterations over it, the times start to drift toward each other and even out. ("Repeats" in the output is the number of times the test was run, with the results being averaged out.) -- Chris Nicholson-Sauls
Nov 16 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Chris Nicholson-Sauls wrote:
 Chris Nicholson-Sauls wrote:
 
 Jarrett Billingsley wrote:

 "Reiner Pope" <reiner.pope REMOVE.THIS.gmail.com> wrote in message 
 news:ejg8qd$475$1 digitaldaemon.com...

 Jarrett Billingsley wrote:
 I'm not sure if this is what you want, but here's a cast-free 'call' 
 function:

 ...code...
Ah! That's an alright tradeoff. I didn't actually know that you could set the .ptr and .funcptr properties of delegates; I thought they were read-only! Cool.
I didn't know this either... and it opens some ideas up to me... Like, perhaps one could do the following: Might actually be slightly cheaper than a normal call in some cases, particularly of Foo and/or bar() are final. Will have to test it... -- Chris Nicholson-Sauls
Well, I tested it. And the results are... pretty neutral, really. Which is a plus in its own right, because it does at least mean one can use this trick without worry. Some exemplar output from the test program: Repeats: 100 Iterations: 1000 List size: 500 Virtual call: 0 sec / 20 msec / 21417 usec Manipulated delegate: 0 sec / 18 msec / 19367 usec Repeats: 100 Iterations: 5000 List size: 500 Virtual call: 0 sec / 86 msec / 87139 usec Manipulated delegate: 0 sec / 86 msec / 86640 usec Repeats: 100 Iterations: 5000 List size: 25 Virtual call: 0 sec / 7 msec / 8117 usec Manipulated delegate: 0 sec / 6 msec / 6901 usec So, yes, there is occasionally some speedup from using the manipulated delegate, but its nothing to scream about. And it appears that, as the size of the data increases, or the number of iterations over it, the times start to drift toward each other and even out. ("Repeats" in the output is the number of times the test was run, with the results being averaged out.) -- Chris Nicholson-Sauls
Well... what do you know. I get back home and take a look over the test again... and find that I actually had made an error. The data wasn't getting reset between the two loops (forgot to call the reset() function... very duh moment)... which means the results for the delegate style were actually an average of its runs /plus/ the runs of the normal call! So, I fixed it... and here are a couple of sample runs: Repeats: 100 Iterations: 1000 List size: 500 Virtual call: 0 sec / 21 msec / 21898 usec Manipulated delegate: 0 sec / 16 msec / 17367 usec Repeats: 100 Iterations: 5000 List size: 500 Virtual call: 0 sec / 97 msec / 98014 usec Manipulated delegate: 0 sec / 93 msec / 94004 usec Repeats: 100 Iterations: 5000 List size: 25 Virtual call: 0 sec / 8 msec / 9436 usec Manipulated delegate: 0 sec / 3 msec / 4211 usec Definitely a more significant difference than I'd previously thought! Still not a massive difference, and the results actually vary quite a bit between runs. (Sometimes by several milliseconds.) And still as the data set size or iterations grow, the times approach equality, sometimes within a couple hundred microseconds. (Every so often, the normal calls when even perform a little faster.) I suppose, if this could cleanly and optimally be generalized into a template, it /might/ provide some benefit to those wanting to eek out as much speed as possible. Albeit with inconsistant benefits. -- Chris Nicholson-Sauls
Nov 16 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Jarrett Billingsley wrote:
 1) For the delegate .funcptr property, would it be possible for it to 
 include the context pointer as the first parameter?  Currently the .funcptr 
 allows us to get the type / call signature of the delegate but it's not 
 possible to actually use the resulting function as there is no way to pass 
 it the context short of dipping into ASM..
I don't see a reasonable way to do that at the moment.
 2) The class/struct .tupleof property is cool, but is there any way to get 
 at the names of the corresponding fields?  Additionally, what would _really_ 
 rock my socks would be a way to get the tuple of the class/struct _methods_. 
 That would probably immediately make many kinds of reflection possible from 
 within the language.
Possibly.
 Indexing tuples rules, btw.
I think we've only begun to see what this is good for. It's so *painful* to do this in C++ that I don't think people have really got that far beyond the first steps.
Nov 15 2006
prev sibling next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
Very cool. Can't wait to play with it some more! --bb
Nov 14 2006
prev sibling next sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
Awesome! I'm really glad you decided to use a seperate keywords for RAII storage and permitting type inference. You also had a different idea of how it should be done, but listened to the community and apparently decided otherwise. You're the man Walter! The other things in the patch look really cool too (syntax cleanup... and I'm eyeballing that .funcptr). Just one little inconsistancy I noticed when running the new compiler: void main() { Foo bar = new Foo(); } scope class Foo { int memberA; } Produces the following error message when compiled: main.d(5): variable main.main.bar reference to auto class must be auto ... yet "auto" is no longer the canonical word for raii. Thank you!
Nov 14 2006
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
I'm not much of a template guy .. good job, I guess, even though it all sounds like C++ish bloat to me. But isn't Reflection more important? :P
Nov 15 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Hasan Aljudy wrote:
 I'm not much of a template guy .. good job, I guess, even though it all 
 sounds like C++ish bloat to me.
 But isn't Reflection more important? :P
Tuples are a form of compile time reflection.
Nov 15 2006
parent reply =?iso-8859-1?q?Knud_S=F8rensen?= <12tkvvb02 sneakemail.com> writes:
On Wed, 15 Nov 2006 00:21:30 -0800, Walter Bright wrote:

 Hasan Aljudy wrote:
 I'm not much of a template guy .. good job, I guess, even though it all 
 sounds like C++ish bloat to me.
 But isn't Reflection more important? :P
Tuples are a form of compile time reflection.
How do you convert a class or a struct to a tuple ???
Nov 15 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Knud Sørensen" <12tkvvb02 sneakemail.com> wrote in message 
news:pan.2006.11.15.11.31.12.751698 sneakemail.com...
 On Wed, 15 Nov 2006 00:21:30 -0800, Walter Bright wrote:

 Hasan Aljudy wrote:
 I'm not much of a template guy .. good job, I guess, even though it all
 sounds like C++ish bloat to me.
 But isn't Reflection more important? :P
Tuples are a form of compile time reflection.
How do you convert a class or a struct to a tuple ???
With .tupleof! class A { int x; float y; } A a = new A(); a.tupleof[0] = 4; a.tupleof[1] = 3.14; I think you can do it on the class type itself as well. This only works for the datafields though.
Nov 15 2006
parent reply Sean Kelly <sean f4.ca> writes:
Jarrett Billingsley wrote:
 "Knud Sørensen" <12tkvvb02 sneakemail.com> wrote in message 
 news:pan.2006.11.15.11.31.12.751698 sneakemail.com...
 On Wed, 15 Nov 2006 00:21:30 -0800, Walter Bright wrote:

 Hasan Aljudy wrote:
 I'm not much of a template guy .. good job, I guess, even though it all
 sounds like C++ish bloat to me.
 But isn't Reflection more important? :P
Tuples are a form of compile time reflection.
How do you convert a class or a struct to a tuple ???
With .tupleof! class A { int x; float y; } A a = new A(); a.tupleof[0] = 4; a.tupleof[1] = 3.14;
So class tuple data must at least follow lexical order, even if the class is not represented internally that way. Interesting. Looks like this is one strong argument against multiple inheritance in D. Sean
Nov 15 2006
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:ejfidl$2b1l$1 digitaldaemon.com...
 So class tuple data must at least follow lexical order, even if the class 
 is not represented internally that way.
That's what I'm worried about too..
Nov 15 2006
prev sibling parent "Craig Black" <cblack ara.com> writes:
 I'm not much of a template guy .. good job, I guess, even though it all 
 sounds like C++ish bloat to me.
 But isn't Reflection more important? :P
Template programming will be used primarily to develop sophisticated libraries to be used by people like you who don't like template programming. Using a template and developing one are two very different things. The typical developer might just shrug at advanced template features, but an advanced library developer will appreciate them very much. BTW, C++ doesn't even come close to having these features. -Craig
Nov 15 2006
prev sibling next sibling parent Samuel MV <samuel jxdesigner.com> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
Thank you, Walter. I'm going to start using it with DDBI right now :)
Nov 15 2006
prev sibling next sibling parent nazo <lovesyao gmail.com> writes:
Great!! I wrote bind. it works fine!

//License: Public Domain
import std.traits,std.typetuple,std.stdio;

template RemoveAt(int i,T,UL...){
   static if(i==0)
     alias UL RemoveAt;
   else
     alias TypeTuple!(T,RemoveAt!(i-1,UL)) RemoveAt;
}

static assert(is(RemoveAt!(1,int,bool,short)==TypeTuple!(int,short)));

template bind(alias func,int i){
   ReturnType!(func) _bind(ParameterTypeTuple!(func)[i] val,TL...)(TL tl){
     return func(tl[0..i],val,tl[i..$]);
   }
   template bind(ParameterTypeTuple!(func)[i] val){
     alias _bind!(val,RemoveAt!(i,ParameterTypeTuple!(func))) bind;
   }
}


void main(){
   writefln(bind!(test,0).bind!("test")("test2","test3"));
//I want to write like this
//writefln(bind!(test,0)!("test")("test2","test3"));
}
Nov 15 2006
prev sibling next sibling parent Max Samuha <maxter i.com.ua> writes:
On Tue, 14 Nov 2006 15:23:50 -0800, Walter Bright
<newshound digitalmars.com> wrote:

Much improved tuple support.

New 'scope' attribute for RAII objects. 'auto' still works the same, but 
will not for much longer. Use 'auto' for type inference.

http://www.digitalmars.com/d/changelog.html

http://ftp.digitalmars.com/dmd.174.zip
Thank you
Nov 15 2006
prev sibling next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
*bows low in supplication* Absolutely awesome. At the rate these Tuples of yours are going, we won't even /need/ a reflection engine -- which means I can toss a lot of concept code. Just a reflection module in Phobos for a clean interface, and voila. Maybe a standard Interface to be implemented, along with a mixin that handles the majority case. Oops, sorry, got on a tangent. Fantastic release; as much as anything, glad to see you sweeping out these old deprecations, and very glad to see a new RAII term that fits. -- Chris Nicholson-Sauls
Nov 15 2006
prev sibling next sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
Excellent work :) I'm very very fond to see auto/scope win over something else! Guess it's time to have a look at those tuples as well!
Nov 15 2006
prev sibling next sibling parent reply antonio <antonio abrevia.net> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
deprecated 'l' numeric literal suffix no longer allowed I always use 'l' for 32 bits signed values. now... Walters deprecates my prefix styling... thank you. Absurd. Walter: change your editor, your font or, simply, don't use 'l' prefix... but don't deprecate me, please.
Nov 15 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
antonio wrote:
 deprecated 'l' numeric literal suffix no longer allowed
 
 I always use 'l' for 32 bits signed values.
 
 now... Walters deprecates my prefix styling... thank you.
 
 Absurd.
 
 Walter:  change your editor, your font or, simply, don't use 'l' 
 prefix... but don't deprecate me, please.
The 'l' suffix was to indicate a long type. You mentioned prefix, not suffix. I think we are talking about different things.
Nov 15 2006
parent antonio <antonio abrevia.net> writes:
Walter Bright wrote:
 antonio wrote:
 deprecated 'l' numeric literal suffix no longer allowed

 I always use 'l' for 32 bits signed values.

 now... Walters deprecates my prefix styling... thank you.

 Absurd.

 Walter:  change your editor, your font or, simply, don't use 'l' 
 prefix... but don't deprecate me, please.
The 'l' suffix was to indicate a long type. You mentioned prefix, not suffix. I think we are talking about different things.
Yes, sorry. Stupidity is usually related with sleepy people.
Nov 15 2006
prev sibling next sibling parent clayasaurus <clayasaurus gmail.com> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
Nice release!
Nov 15 2006
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
The Phobos page is missing a link to std.traits in the left column!
Nov 17 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Tomas Lindquist Olsen wrote:
 The Phobos page is missing a link to std.traits in the left column!
And one for std.typetuple as well. -- Chris Nicholson-Sauls
Nov 17 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 Much improved tuple support.
 
 New 'scope' attribute for RAII objects. 'auto' still works the same, but 
 will not for much longer. Use 'auto' for type inference.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.174.zip
Nice release. One minor nitpick: In http://www.digitalmars.com/d/template.html: "A Tuple is not a type, an expression, or a symbol. It is a sequence of any mix of types, expressions or symbols." Can we change these terms, so as to use the term "value" instead of "expression"? "expression" gives the idea of the information being the expression tree, which is not the case, it's just the value. Note as other parts of the doc use the term "value": "Template parameters can be types, values, symbols," (and likewise should Tuples be described) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 18 2006