On Thursday, 31 August 2017 at 19:36:00 UTC, kinke wrote:
On Wednesday, 30 August 2017 at 15:35:57 UTC, bitwise wrote:
-What if I want an event to lock a shared mutex of the
enclosing object, without storing a pointer to that mutex
inside the event itself (and every single other event in the
object)?
-What if I want an event to call a method of the enclosing
object when a handler is added (without keeping a pointer to
it inside the actual event)?
So in essence, you'd like something like this to work, right?
struct Event(alias __parent, Handler) {
enum parentHasLock = __traits(compiles, __parent.lock());
...
void opCall()(Parameters!Handler args)
{
static if (parentHasLock)
__parent.lock();
...
}
}
struct Host1 {
Event!Handler onChanged;
Event!Handler onClosed;
}
and have the compiler internally instantiate something like
Event!(/* parent type */ Host1, /* .offsetof in parent in order
to deduce the __parent address from Event's &this */ 0, Handler)
Event!(Host1, N, Handler)
Something like that ;)
I played around with this idea while trying to create a library
implementation of properties for C++. `offsetof` in C++ is unsafe
though, which I think was due to how multiple inheritance works.
It was only recently allowed by the standard, with limitations
that make it all but useless:
See restrictions on "standard layout class"
http://www.cplusplus.com/reference/cstddef/offsetof/
IMO though, this path is still fraught with peril, even if it
works in D. The declaration of an event would have to be very
noisy, and full of extra template parameters that only existed to
supplement the underlying hack. And it still wouldn't allow
invocation of host object code, without even more painful bloat.
