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