DIP30, delegates more destruction for your pleasure

deadalnix deadalnix at gmail.com
Wed Mar 13 20:12:17 PDT 2013


On Wednesday, 13 March 2013 at 18:54:29 UTC, Maxim Fomin wrote:
> From "Fully typed delegates": "Delegate's context is assumed to 
> be of type void*. However, it can be specified as a type after 
> the parameter list ".
>

Pointer already cast to void* so that isn't really new. ref are 
pointer behind the hood.

This is necessary as the context type is especially important for 
value types, not really for reference/pointers.

> This does not look like the best idea: 1) context pointer may 
> point to function frame with several different objects, 2) 
> there are no evidences in th DIP about which problems are 
> solved by ability to append explicit type of context pointer.
>

1) It is explained : context is a pointer to a tuple.
2) It does allow value type as context, which in return allow to 
unify many construct into delegates. It also solve the qualifier 
transitivity problem.

> From " UFCS as delegates": example with function foo(ref uint 
> a) raises concern about ABI implementation. Currently context 
> pointer is passed through RDI and arguments are passed 
> differently. There would be a problem with functions like foo() 
> which do not know from where to take an argument - are they 
> called directly or like a closure?
>

I don't think ABI should be part of D spec. Or should it ?

Anyway, I don't see any reason to have all kind of different ABI 
for function call, and this is a good opportunity to unify 
everything using the context as a regular, first argument.

> Frankly, I see this simpler: delegate = function pointer + data 
> pointer, so they should follow language rules (especially 
> regarding qualifiers).
>

It is a tempting idea, but do not work. Consider :

void delegate() immutable a;
const void delegate() b = a;

This would be forbidden as covariance of function parameters and 
transitivity act in opposite directions.


More information about the Digitalmars-d mailing list