On Saturday, 31 October 2015 at 02:39:19 UTC, Tofu Ninja wrote:
On Friday, 30 October 2015 at 21:38:40 UTC, bitwise wrote:
On Thursday, 29 October 2015 at 01:14:35 UTC, Tofu Ninja wrote:
On Thursday, 29 October 2015 at 00:11:06 UTC, Tofu Ninja
wrote:
[...]
Actually never mind, what I just said was basically auto
override for this() so its not really any different. And it
is kinda limited with some problems.
Sorry, I'm still not clear on whether or not template static
this would work for you.
Personally, I don't need dynamic dispatch or per-instance
access. For me, as long as class info is generated per class
and stored statically, that would suffice. I could always have
a base method look up what it needs at runtime by type name or
something.
An example would be generating a serializer for a class in
template static this to be used at runtime.
Bit
I could make it work the same way you did, but would rather a
solution that did not involve a AA lookup.
You're probably right. My main use case would be serialization
which is inherently slow anyways, so I figured it wouldn't
matter. I'm trying to think of how this proposal can be kept as
simple as possible to maximize the chances of it being accepted,
and I couldn't think of enough use cases to add value to the
virtual function approach.
The more I think about it though, the more uses I come up with:
-automatic generation of toString()
-returning class specific type/serialization info
-automatic implementation of visitors!!
I don't think I have to explain the value of being able to do
this:
void accept(auto this This)(Visitor v) {
v.visit(this);
}
So I guess I'm back on the side of "auto override" functions. I
would prefer a better syntax though. Maybe just "auto" like the
example above instead of "auto override".... or maybe
"@synthesized" in front of the function like this:
@synthesized void accept(this This)(Visitor v) {
v.visit(this);
}
Bit
