On Tuesday, 16 June 2020 at 15:50:07 UTC, jmh530 wrote:
On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote:
[snip]
Pretty cool, thanks for the fixups.
It may make for a good documentation example, in that it may
help make clear that you need to pass the module in somehow
when dealing with non-member functions (AFAICT). You could
include a comment about how it would be different if it were
split into separate files.
Good point.
In your original example, is there any issue if we then make
transform a templated non-member function that is generic over
types like Adder (maybe there is an enum hasAddableMember that
is true for Adder and false for Plus1)?
I was going to say "it should work" but instead I wrote the code
and... it does. It all falls out of how UFCS works and usual
language rules.
https://github.com/atilaneves/tardy/blob/feb26282608081098134c8846be87d398772ccb0/tests/ut/polymorphic.d#L102
https://github.com/atilaneves/tardy/blob/feb26282608081098134c8846be87d398772ccb0/tests/modules/ufcs/template_.d
Am I right that the shared static constructor in vtable means
that there is one vtable for all the instances?
All instances of the same concrete type share the same vtable
pointer, yes. Originally I built the vtable on the spot with
`new` and assigned to each function pointer but then I realised
that was a waste of time and allocations - the vtable is unique
per concrete type.
Are there any technical issues preventing Polymorphism from
accepting a class in addition to an interface?
None. It could even accept a struct, really.
