On Wednesday, 28 August 2013 at 15:20:34 UTC, Artur Skawina wrote:
> It's hard to tell what your actual requirements are; this discriminated union might help. It does a bit more than what you ask for, as it also gives access to /data/, not just methods; this shouldn't be a problem.

 Requirements, I don't have any written down but I have it in my head. I want to replace specific functions, I don't want to use a vTable (or pointer or anything like that). They are replaced based on fixed criteria of what the changed behavior is/needs to be.

 I want to use OO and inheritance to split it into logical portions (after sorta implementing inheritance/semi-polymorphism in pure C functions the code got ugly fast and is difficult to navigate through).


> The data access parts could be even more efficient, but I failed to figure out a way to check for perfectly overlapping fields at CT - offsetof doesn't work after an alias-this conversion takes place, CTFE does not allow the pointer arithmetic required, and when ctfe does, the result can be false negatives. Maybe someone else has an idea how to correctly implement the 'atSameOff' function below (which would make accesses to compatible data members free; right now the type check is never omitted. It could also be done using manual annotations, but those shouldn't be necessary...)

 It looks like I'll have to read this in more detail when I can wrap my head around it. I'll give it a look.

 Mixin is suppose to inject code as though you posted it there, correct? I've got a case with my LSPS function(s) where it fails my tests when I use the mixin, but if I copy/paste the output from the screen back into the source it works just fine.

 All these new headaches with the new version and coming back are starting to tick me off.