May 31, 2012
On Thu, 31 May 2012 12:25:20 +0200, Sandeep Datta wrote:

>>   //fptr = handleRequest; // will not work, because it is
>> "understdood"
>> as:
>>                           // fptr = handleRequest();
>>
>>
> But do we really need this feature? Typing () does not seem to be too
> much work besides we can use properties if we really need to drop the
> brackets. And given the fact that properties have well understood use
> cases (see
> http://msdn.microsoft.com/en-us/library/bzwdh01d
(VS.71).aspx#cpconpropertyusageguidelinesanchor1)
> I am not sure using functions as properties is such a good idea.
> 
>>   fptr = &handleRequest;  // This will work if we have only one
>> handleRequest();
>>                           // If you uncomment the first one,
>> you are in
>> trouble
> 
> Can't we use auto-inferencing here to select the right method since fptr has the required type information?

Nope, i specifically made this example because D makes no difference between two or more functions with different return types.


-- 
Dejan Lekic
  mailto:dejan.lekic(a)gmail.com
  http://dejan.lekic.org
May 31, 2012
>
> If we removed the requirement for the ampersand, along with requiring parentheses for non-property functions, code which expected to call the function without parentheses would silently compile, but not do what was intended.


Consider this...

float handleRequest() {
 return 1.0f;
}

float x = handleRequest; //compilation error

or

auto x = handleRequest;

writefln("%f", x); //compilation error


I think we'd get a compile time error for most cases without significant changes to the compiler. But the edge cases if any can probably be detected at compile time with modifications to the compiler.

Here is an edge case (for reference)...

writefln(x);// will now print the address of the function
May 31, 2012
On Thu, 31 May 2012 08:27:17 -0400, Sandeep Datta <datta.sandeep@gmail.com> wrote:

>>
>> If we removed the requirement for the ampersand, along with requiring parentheses for non-property functions, code which expected to call the function without parentheses would silently compile, but not do what was intended.
>
>
> Consider this...
>
> float handleRequest() {
>   return 1.0f;
> }
>
> float x = handleRequest; //compilation error
>
> or
>
> auto x = handleRequest;
>
> writefln("%f", x); //compilation error

What about:

handleRequest;

-Steve
May 31, 2012
> What about:
>
> handleRequest;
>
> -Steve

Yes I have considered that but that should be pretty easy to detect and flag for correction, isn't it? I mean the compiler already knows it is supposed to be a call to the handleRequest function (if it doesn't how will it generate code for it?) so it should just let the user know this syntax is not supported anymore.
May 31, 2012
> Nope, i specifically made this example because D makes no difference
> between two or more functions with different return types.

Are you talking about co-variance? Could you please explain what you mean when you say D does not distinguish between return types (possibly by pointing to contexts in which this happens)? If yes then I think this a different case all together. In this case it seems picking the right function is doable, co-variance notwithstanding. Note I am not saying this can be done without making any changes to the compiler/language but whatever changes are required IMO will be small.
May 31, 2012
On Thursday, May 31, 2012 11:36:47 Sandeep Datta wrote:
> Hi,
> 
> I was going through some sample code online and came across the following code fragment...
> 
> 	listenHttp(settings, &handleRequest); //Where handleRequest is a
> function
> 
> My question to you is (as the title says) is the address-of operator (&) really needed here? Wouldn't it be better to consider handleRequest to be a reference to the actual function? I think this will make the system consistent with the way variables work in D. IMO this will bring functions/delegates closer to being first class objects in D.
> 
> What do you think?

1. It's needed so that you can call it when calling C code.

2. Just because ref is often better than a pointer doesn't mean that it's never valuable to be able to pass a pointer to a variable.

3. ref doesn't work with variadic templates very well. Take a look a std.getopt.getopt. It takes pointers, not refs, and there isn't a way to make it take refs.

4. & is useful for getting function pointers.

There is _zero_ roason to get rid of & IMHO.

- Jonathan M Davis
June 01, 2012
Le 31/05/2012 11:58, Dejan Lekic a écrit :
> On Thu, 31 May 2012 11:36:47 +0200, Sandeep Datta wrote:
>
>> Hi,
>>
>> I was going through some sample code online and came across the
>> following code fragment...
>>
>> 	listenHttp(settings,&handleRequest); //Where handleRequest is a
>> function
>>
>> My question to you is (as the title says) is the address-of operator (&)
>> really needed here? Wouldn't it be better to consider handleRequest to
>> be a reference to the actual function? I think this will make the system
>> consistent with the way variables work in D. IMO this will bring
>> functions/delegates closer to being first class objects in D.
>>
>> What do you think?
>>
>> Regards,
>> Sandeep Datta.
>
> It is needed.
>
> Consider this example:
>
> import std.stdio;
>
> /*
> float handleRequest() {
>    return 1.0f;
> }
> */
>
> int handleRequest() {
>    return 200;
> } // handleRequest() function
>
> int main() {
>    int function() fptr;
>    //fptr = handleRequest; // will not work, because it is "understdood"
> as:
>                            // fptr = handleRequest();
>
>    fptr =&handleRequest;  // This will work if we have only one
> handleRequest();
>                            // If you uncomment the first one, you are in
> trouble
>
>    int val = handleRequest; // calls handleRequest() actualy
>
>    //listenHttp(settings, fptr); // no need for&  because fptr is an
> object of "int function()" type
>
>    writeln(val); // OUTPUT: 200
>
>    return 0;
> } // main function
>
>
>

This behavior is planed to be deprecated. The & behavior should go as well I think.
June 01, 2012
On Thu, 31 May 2012 08:40:51 -0700, Jonathan M Davis wrote:

> On Thursday, May 31, 2012 11:36:47 Sandeep Datta wrote:
>> Hi,
>> 
>> I was going through some sample code online and came across the following code fragment...
>> 
>> 	listenHttp(settings, &handleRequest); //Where handleRequest is a
>> function
>> 
>> My question to you is (as the title says) is the address-of operator (&) really needed here? Wouldn't it be better to consider handleRequest to be a reference to the actual function? I think this will make the system consistent with the way variables work in D. IMO this will bring functions/delegates closer to being first class objects in D.
>> 
>> What do you think?
> 
> 1. It's needed so that you can call it when calling C code.
> 
> 2. Just because ref is often better than a pointer doesn't mean that it's never valuable to be able to pass a pointer to a variable.
> 
> 3. ref doesn't work with variadic templates very well. Take a look a std.getopt.getopt. It takes pointers, not refs, and there isn't a way to make it take refs.
> 
> 4. & is useful for getting function pointers.
> 
> There is _zero_ roason to get rid of & IMHO.
> 
> - Jonathan M Davis

+1 100%

I would add that "fptr = &function;" makes it _clear_ what is going on there, otherwise I would have to go and find what "function" is...

-- 
Dejan Lekic
  mailto:dejan.lekic(a)gmail.com
  http://dejan.lekic.org
June 01, 2012
On 5/31/12, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> 2. Just because ref is often better than a pointer doesn't mean that it's never valuable to be able to pass a pointer to a variable.

5. And '&' documents code better at the call site. I personally refuse to use out/ref arguments because the call site makes it ambiguous whether an argument is passed by reference or not.
June 01, 2012
> I would add that "fptr = &function;" makes it _clear_ what is going on
> there, otherwise I would have to go and find what "function" is...

There are two contradictory issues at work here which need to be balanced with each other...

1. While writing code we expect the compiler to understand what we want to do without writing a lot of code. Compiler inference is a boon here. D has some features supporting this (like auto).

2. While reading code and while trying to reason about the program we want the program to be self documenting and simple. Often as is the case with natural languages some redundancy is required to accomplish this. This makes a language verbose and increases the difficulty / effort required for writing programs.

We don't have many tools which can help us with item #1 but we do have tools which can help significantly with item #2 (eg. IDEs, static code analyzers etc) so IMHO we should design our languages to help us with item #1.

Removing the ampersand is one small step in this direction. Though I agree upfront I have not mastered all the nuances of D to even know if this is possible at all at this point of time.