On Friday, 28 April 2017 at 07:07:44 UTC, Daniel N wrote:
On Friday, 28 April 2017 at 05:32:36 UTC, Carl Sturtivant wrote:
On Friday, 28 April 2017 at 04:44:44 UTC, Carl Sturtivant
wrote:
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:
On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant
wrote:
On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven
Schveighoffer wrote:
I think you can appreciate that this doesn't scale.
Imagine a case which has 2 or 3 optional alias this items.
-Steve
Agreed, not manually, as it is exponential in the number of
conditions.
Image using frameworks which conveniently allow adding
features to a struct...
struct Beholder
{
mixin Entity!Movable;
mixin Render!"Beholder.png";
}
... then you couldn't even solve it manually without
rewriting the framework.
With distributed 'alias this' you could seamlessly combine
any number of frameworks from different vendors.
Please explain "seamlessly" with the prospect of name
collisions.
:) Disclosure: I have a negative view of mixin templates.
Entanglement with names at the landing site is unhappy.
You don't have to fear mixin collisions since there is an
awesomely designed builtin feature to solve this issue.
mixin template fun() { int a; }
struct A
{
mixin fun f1;
mixin fun f2;
}
void main()
{
auto a = A();
a.f1.a = 1;
a.f2.a = 2;
}
If having templates with dynamic bindings (set at the landing
site) of some kind is obligatory, then this is about as good as
it can get. I wouldn't call it awesome except in the sense that
it cleverly makes the best of an awkward situation. It's not a
clean abstraction: subsequently mixing in more "features of a
struct" into your struct can make a formerly usable name in the
outside world unusable.
However I am trying to arrive at a mechanism whereby this is
unnecessary.
AliasThis has the same issues as led to the definition of mixin
templates if there are multiple such. So there are two broad
paths that could be followed. The first is to just swallow a
similar mechanism as mixin templates, and try to allow arbitrary
interaction among many distributed AliasThis declarations with
fallback to fully qualified names in the event of ambiguity as in
your example.
The second path is to endeavor to create a different mechanism
that does not suffer from that approach, so an additional entity
can be added to the list of things being aliased-to-this without
making existing names unusable outside of the definition being
made, exactly the way mixin templates don't.
I am trying to explore this second path.
