Janice Caron, el 30 de enero a las 08:36 me escribiste:
> On Jan 30, 2008 8:16 AM, Don Clugston <dac@nospam.com.au> wrote:
> > How do you declare
> > oldFashionedCFunction() ?
> 
> The old fashioned way?
> 
>     extern(C) void (*callback)(int,int);

That's that the keyword function is for. What's the point of removing it if we need it?

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
"CIRILO" Y "SIRACUSA" DE "SEÑORITA MAESTRA": UNO MUERTO Y OTRO PRESO
	-- Crónica TV

Janice Caron wrote:
> On Jan 30, 2008 11:17 AM, Don Clugston <dac@nospam.com.au> wrote:
>>>>     extern(C) void (*callback)(int,int);
>> That's just 'function', using the hideous C syntax.
> 
> Yes, that is precisely my suggestion. I see that as an advantage, not a disadvantage, because it would encourage people to use "delegate", unless they absolutely couldn't.
<snip>
> On the other hand, if you want to interface with C, then you shouldn't be surprised if you have to use hideous C syntax.

I’d go a step further:  If you’re interfacing to a C function, you
presumably have its declaration handy -- in C syntax.  Why have a
keyword that’s only useful in the one circumstance where it’s not needed?

- --Joel

Janice Caron wrote:
> On Jan 30, 2008 11:17 AM, Don Clugston <dac@nospam.com.au> wrote:
>>>>     extern(C) void (*callback)(int,int);
>> That's just 'function', using the hideous C syntax.
> 
> Yes, that is precisely my suggestion. I see that as an advantage, not
> a disadvantage, because it would encourage people to use "delegate",
> unless they absolutely couldn't.
> 
> All I'm saying is, if you're working in D alone, you can get along
> just fine using "delegate" instead of "function", and therefore the
> keyword "function" is unnecessary.
> 
> On the other hand, if you want to interface with C, then you shouldn't
> be surprised if you have to use hideous C syntax.
> 
> So we /could/ ditch "function" and have one fewer keyword.

Ah, OK -- that's a reasonable argument. Certainly it does seem that 'function' is becoming a 'foreign' concept to D; you almost always want to use 'delegate' instead.

Note (1) 'function' has a different meaning inside is() expressions.

alias void function(int,int) Foo;
static assert (is(Foo == function)); // fails!


Note (2) function pointers do pop up in other places even if you program exclusively in D, for example in reflection (compile time and runtime). The vtable is full of function pointers, not delegates.

Walter Bright wrote:
> Edward Diener wrote:
>> Perhaps there are some implementation issues regarding this which I do
>> not understand but these should be overcome in order to present a single
>> interface to the callable concept. Perhaps this has been
>> discussed ad nauseam on this NG already, so please correct me if I do
>> not understand all the ramifications of uniting all callable types under
>> the single idea of 'delegate' while perhaps keeping 'function' around
>> merely for backward compatibility with old code until eventually it is
>> dropped.
> 
> To merge the two requires the generation of thunks at runtime to manipulate the parameters and calling convention. It's doable, but not simple.

Can't say I've thought this through, but what if delegates simply worked for all functions with the extern (D) calling convention, regardless of scope?  That would cover the vast majority of cases, and make other calling conventions somewhat of a special case, which they are anyway.


Sean

Joel C. Salomon wrote:
> Janice Caron wrote:
>> On the other hand, if you want to interface with C, then you shouldn't
>> be surprised if you have to use hideous C syntax.
> 
> I’d go a step further:  If you’re interfacing to a C function, you
> presumably have its declaration handy -- in C syntax.  Why have a
> keyword that’s only useful in the one circumstance where it’s not needed?

How about when you're interfacing with a different language and are using the C calling convention as a 'lingua franca'?

(Or even linking DMD-compiled code and GDC-compiled code, since they use different calling conventions for D functions)

Janice Caron wrote:
> On 1/30/08, Edward Diener <eddielee_no_spam_here@tropicsoft.com> wrote:
>> You might need plain function pointers but you do not need 'function'. A
>> 'delegate' which encompassed a 'function', with the object pointer part
>> of the delegate being null in that particle case, should be implicitly
>> convertible to a C function pointer.
> 
> In general, the compiler cannot tell at compile time whether or a not
> a value is null at runtime (though in an expression like &f it
> obviously can), so I don't think it can be quite that automatic.

But it can generate code which checks at run-time if this is the case and takes the correct action. In the case of converting a delegate which has a non-null value as the object pointer, the code generated if one tries to cast it to a plain C function pointer could throw an exception.

On Jan 30, 2008 11:24 PM, Edward Diener <eddielee_no_spam_here@tropicsoft.com> wrote:
> But it can generate code which checks at run-time if this is the case and takes the correct action. In the case of converting a delegate which has a non-null value as the object pointer, the code generated if one tries to cast it to a plain C function pointer could throw an exception.

Good point.

Along similar lines, the compiler could generate code which checks for null dereferences, but I don't see that happening anytime soon. :-(

These are exactly the sort of things that ought to be in debug (but
not release) builds (IMO).