What's left for 1.0?

[Bill Baxter]

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


Ugh.  I just hit this using my flexible signals and slots wrapper.

    widget.value_changed.fconnect(&other_widget.value);

Doh!
I really don't want writing a gui to involve gobs of code like:

   widget.value_changed.fconnect!(
        typeof(&other_widget.value))(&other_widget.value);


Now I really wish I had a tool to find property-like methods in my 
source code so I can at least make sure they are in the right lexical 
ordering. :-(

Has there been any bug/enhancement filed on this that I can keep a watch on?

For my case I'm not even sure what would be the right thing for it to 
do.  What I really need to happen is for fconnect to prefer methods with 
non-trivial argument lists, but I can't rule out the possibility someone 
actually wants to connect up a no-argument slot like "updateGui()" to a 
signal.

Maybe we need to be able to optionally specify the arguments when taking 
a delegates, like:

     connect(&obj.value(int));

-bb