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