Kirk McDonald wrote:
> Bill Baxter wrote:
>> BCS wrote:
>>> There is no way to differentiate between function overloads.
>>>
>>>
>>> int foo(){ return 0;}
>>> int foo(int i){ return 0;}
>>>
>>>
>>> int bob()
>>> {
>>>         // foo() or foo(int)?
>>>     auto fn = &foo;
>>>     auto tmp = TemplateTakingFn!(foo);
>>> }
>>
>> That should probably be an "error: ambiguous" if it isn't already, but anyway can't you do   'int function() fn = &foo' to get the one you want?
>>
>> --bb
> 
> I've played with just about every permutation of this problem during the course of writing Pyd.
> 
> int foo() { return 0; }
> int foo(int i) { return 0; }
> 
> void main() {
>     auto fn = &foo; // Uses the lexically first function
>     static assert(is(typeof(fn) == int function()));
>     fn();
>     //fn(12); // Error: expected 0 arguments, not 1
>     int function(int) fn2 = &foo; // Works
>     fn2(12);
> }
> 
> In writing Pyd, I've come to the conclusion that if you have a template that accepts an arbitrary function as an alias parameter (and then does anything involving the type of that function), you should always have a second parameter representing the type of the function. (And you can easily make this second parameter have a default value of typeof(&fn).) In this way the user can be sure the template is getting the proper overload of the function.

If you had some extra condition like "I want to match the version with the most arguments" can you think of some way to make that work with the current D?

--bb

Bill Baxter wrote:
> Kirk McDonald wrote:
>> In writing Pyd, I've come to the conclusion that if you have a template that accepts an arbitrary function as an alias parameter (and then does anything involving the type of that function), you should always have a second parameter representing the type of the function. (And you can easily make this second parameter have a default value of typeof(&fn).) In this way the user can be sure the template is getting the proper overload of the function.
> 
> If you had some extra condition like "I want to match the version with the most arguments" can you think of some way to make that work with the current D?
> 
> --bb

No, because there is no way to get another overload of a function beyond the first without knowing the type of the overload.

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

Kirk McDonald wrote:
> Bill Baxter wrote:
>> Kirk McDonald wrote:
>>> In writing Pyd, I've come to the conclusion that if you have a template that accepts an arbitrary function as an alias parameter (and then does anything involving the type of that function), you should always have a second parameter representing the type of the function. (And you can easily make this second parameter have a default value of typeof(&fn).) In this way the user can be sure the template is getting the proper overload of the function.
>>
>> If you had some extra condition like "I want to match the version with the most arguments" can you think of some way to make that work with the current D?
>>
>> --bb
> 
> No, because there is no way to get another overload of a function beyond the first without knowing the type of the overload.
> 

Hmm, I was hoping maybe there's a way to use a series of templates like

    void set_function(Ret,A1,A2,A3)(Ret delegate(A1,A2,A3) dg) { ... }
    void set_function(Ret,A1,A2)(Ret delegate(A1,A2) dg) { ... }
    void set_function(Ret,A1)(Ret delegate(A1) dg) { ... }
    void set_function(Ret)(Ret delegate() dg) { ... }

where ifti would prefer the one with more arguments to one with fewer.
Of course if that were the solution it would take us right back into the bad old days before TypeTuples.

--bb

Bill Baxter wrote:
> Kirk McDonald wrote:
>> Bill Baxter wrote:
>>> Kirk McDonald wrote:
>>>> In writing Pyd, I've come to the conclusion that if you have a template that accepts an arbitrary function as an alias parameter (and then does anything involving the type of that function), you should always have a second parameter representing the type of the function. (And you can easily make this second parameter have a default value of typeof(&fn).) In this way the user can be sure the template is getting the proper overload of the function.
>>>
>>> If you had some extra condition like "I want to match the version with the most arguments" can you think of some way to make that work with the current D?
>>>
>>> --bb
>>
>> No, because there is no way to get another overload of a function beyond the first without knowing the type of the overload.
>>
> 
> Hmm, I was hoping maybe there's a way to use a series of templates like
> 
>     void set_function(Ret,A1,A2,A3)(Ret delegate(A1,A2,A3) dg) { ... }
>     void set_function(Ret,A1,A2)(Ret delegate(A1,A2) dg) { ... }
>     void set_function(Ret,A1)(Ret delegate(A1) dg) { ... }
>     void set_function(Ret)(Ret delegate() dg) { ... }
> 
> where ifti would prefer the one with more arguments to one with fewer.
> Of course if that were the solution it would take us right back into the bad old days before TypeTuples.
> 
> --bb

.. And it doesn't work.  Just gives you the lexical ordering again:

import std.stdio : writefln;

void func(int a, float b)
{
    writefln("func(int, float)");
}
void func(int a)
{
    writefln("func(int)");
}
void func()
{
    writefln("func()");
}

void do_it(A1,A2)(void function(A1, A2) f) {
    f(1,2.0);
}
void do_it(A1)(void function(A1) f) {
    f(3);
}
void do_it()(void function() f) {
    f();
}

void main()
{
    // no dice, still you get the func that's lexically first
    do_it(&func);
}

Your solution of passing the parameters for the version you want to the template is ok, except with the way IFTI works it's a headache when there are other parameters that could otherwise be guessed by IFTI that suddenly have to be specified too.


--bb

I haven't been programming (for fun) for many months now and I decided to see what is happening to D and I see it will be called 1.0 soon. Many bugs fixed in the cangelog, so I decided to give it a try. Maybe even update rulesPlayer...

Thread.getThis inside dynamically linked DLL still causes access violation. I brought up this long time ago but no attention was payed...
I don't remember any details now but when I was dealing with the problem  I dug deeper cause it was a real show stopper for me... So I really wouldn't call the DMD's DLL support 'decent'. I don't know if this will be ever fixed so lets hope for DDL :D

struct point p={1,2}; is still not working!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! This is shocking for so advanced language! (I saw this was discussed but whatever I give my support on this point)


Wish you the best guys.



Craig Black wrote:
> This is not a 1.0 blocker, but it is a blocker my development.  D doesn't have a good solution for cross-platform dynamic libraries.  Full dynamic class loading would be nice, but D should at the very least do what C++ does and support overridding virtual method across DLL boundaries.
> 
> I have a C++ code base that I want to port to D, but it uses an cross-platform plugin system that I can not replicate with D in its current state.  I don't think this kind of functionality will get into 1.0, and that's OK, just as long as it does with the next year or so.
> 
> Other than that, I can see no shortcoming in D that would hinder development.  I'm really very anxious to port my code, but I don't want to start until D is ready.  On the positive side of things, I forsee gobs and gobs of C++ template code shrinking down to nothing, and a fifteen minute compile time reduced to less than a minute.
> 
> -Craig 
> 
>