Ok, so here's what I'll do unless someone objects:

==delegate

remains the same

==return

for functions, delegates, and pointers to functions, gets the return type

==function

gets the prototype as a tuple (this breaks existing code)

Also, is there a need for:

==class

getting the base class?

Kirk McDonald wrote:
> Which brings up another point: It's really great that you added the .ptr property to delegates in 0.168, but it would also be great to have a .fn property to access the function pointer. (And optimally, this pointer would be of the right type, and not just a void*.)


Ok, but as long as everyone realizes the function cannot be called via that function pointer (because the calling convention for delegates is different because there's that extra parameter). The type of the .funcptr would only be useful for extracting other information.

Walter Bright wrote:
> Kirk McDonald wrote:
>> Which brings up another point: It's really great that you added the .ptr property to delegates in 0.168, but it would also be great to have a .fn property to access the function pointer. (And optimally, this pointer would be of the right type, and not just a void*.)
> 
> 
> Ok, but as long as everyone realizes the function cannot be called via that function pointer (because the calling convention for delegates is different because there's that extra parameter). The type of the .funcptr would only be useful for extracting other information.

The hope is that I could then say something like this:

class Foo {
    void func() { }
}

void main() {
    void delegate() dg;
    Foo f = new Foo;
    dg.ptr = &f;
    dg.funcptr = &Foo.func;
    dg();
}

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

Kirk McDonald wrote:
> The hope is that I could then say something like this:
> 
> class Foo {
>     void func() { }
> }
> 
> void main() {
>     void delegate() dg;
>     Foo f = new Foo;
>     dg.ptr = &f;
dg.ptr = f;
>     dg.funcptr = &Foo.func;
>     dg();
> }

and it should work.

Walter Bright wrote:
> 
> Ok, so here's what I'll do unless someone objects:
> 
> ==delegate
> 
> remains the same
> 
> ==return
> 
> for functions, delegates, and pointers to functions, gets the return type
> 
> ==function
> 
> gets the prototype as a tuple (this breaks existing code)

It sounds fine, but it still lacks the ability to get the delegate type of a function... Unless, of course there is a way to derive the delegate/function type from a tuple and return type ;)


> Also, is there a need for:
> 
> ==class
> 
> getting the base class?

I'm sure someone would find a use case for that, but wouldn't it break existing code too ? Currently using 'class' inside IsExpression simply yields the same type as the one in question. An alternative approach would be to allow .super to be accessed from outside of a class, so typeof(Foo.super) would become a valid expression.


--
Tomasz Stachowiak

While the topic is function, "there arguments and what not" could we get a fix to issue #52 (I think that is the number). As it stands, there is no way to reference an overloaded function with out already knowing it's type.

int foo(char c){return 0;}
void foo(long l){}

auto fn = &foo;
// the foo used changes if the order of the above changes.

this could also cause problems while attempting to call overloaded functions the an overloaded function as a parameter

void fuf(int function(char) fn){}
void fuf(void function(long) fn){}

fuf(&foo);	// what is used here

BCS wrote:
> While the topic is function, "there arguments and what not" could we get a fix to issue #52 (I think that is the number). As it stands, there is no way to reference an overloaded function with out already knowing it's type.
> 
> int foo(char c){return 0;}
> void foo(long l){}
> 
> auto fn = &foo;
> // the foo used changes if the order of the above changes.
> 
> this could also cause problems while attempting to call overloaded functions the an overloaded function as a parameter
> 
> void fuf(int function(char) fn){}
> void fuf(void function(long) fn){}
> 
> fuf(&foo);    // what is used here
> 

Pyd grapples with this problem by passing around all "real" functions as a combination of function alias and function type, which are typically referenced as fn and fn_t, respectively, in the code.

Given your overloads of foo, above, saying
    def!(foo);
will wrap the first overload in Pyd. To wrap the other overload, the user has to explicitly provide its type (and an alternate name):
    def!(foo, "foo2", void function(long));

A related problem is the issue of default arguments.

void bar(int i, real r=5.8, char[] s="hello") {}

typeof(&bar) is void function(int, real, char[]). Attempting to say
    void function(int) fn = &bar;
does not work. (It fails to compile as written. Casting &bar to the proper type allows it to compile, but results in odd behavior.) Similarly, saying
    void function(int, real, char[]) fn = &bar;
    fn(1);
doesn't work. (Calling fn with the wrong number of arguments is an error.)

One of the additions I made to the metaprogramming library I use in Pyd is a simple little array of template functions that allows you to get a function pointer calling the first n arguments of a function. The original version used a mass of templates; the new variadics would allow it to look something like this:

template firstArgsT(alias fn, uint i, fn_t) {
    alias RetType!(fn_t) R;
    alias tupleFromFn_T!(fn_t)[0..i] T; // A theoretical template

    R func(T t) {
        return fn(t);
    }
}

template firstArgs(alias fn, uint i, fn_t = typeof(&fn)) {
    alias firstArgsT!(fn, i, fn_t).func firstArgs;
}

Some sort of streamlining of this process would be appreciated as well.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

BCS wrote:
> While the topic is function, "there arguments and what not" could we get a fix to issue #52 (I think that is the number). As it stands, there is no way to reference an overloaded function with out already knowing it's type.
> 
> int foo(char c){return 0;}
> void foo(long l){}
> 
> auto fn = &foo;
> // the foo used changes if the order of the above changes.
> 
> this could also cause problems while attempting to call overloaded functions the an overloaded function as a parameter
> 
> void fuf(int function(char) fn){}
> void fuf(void function(long) fn){}
> 
> fuf(&foo);    // what is used here
> 

Seems like it ought to be simple enough to provide this just by allowing a tuple of type symbols in the address-of-function expression.  Or in other words, to get the foo(long) in your first example, rather than foo(char) just do:
# auto fn = &foo(char);

which is still shorter than the explicit:
# int function (long) foo = &foo;

And again in your second example:
# fuf(&foo(long));

which has grown in this case, but not by a lot, and certainly the type information shouldn't be neccessary if there are no overloads.

-- Chris Nicholson-Sauls

Walter Bright schrieb am 2006-11-07:
>
> Ok, so here's what I'll do unless someone objects:
>

<snip>

> Also, is there a need for:
>
>==class
>
> getting the base class?

I could have used this once or twice.

How about the index type of an associative array?

Thomas