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

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

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.

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.

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 :)

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"));
}

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.

Ary Manzana wrote:
> However in the spec says "Declaration statements declare and initialize variables". Should the spec be corrected?

It already has been <g>.

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

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)