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

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

"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.

"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.

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

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!

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

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.

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.

"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..