[tdpl] Multiple alias this

[IgorStepanov]

This PR introduces multiple alias this.
The old alias this implemenation doesn't imply alias this conflicts.
All alias this-es in old implementation are serializable: compiler successively applies a, a->aliasthis, a->aliasthis->aliasthis while right expression is not found.

This implementation allows tree of alias this subtypes.
Type can has a direct "alias this"-es and "alias this"-es, inherited from base classes/interfaces. Thus, there can be conflict between several matching "alias this"-es.
In common case compile should raise error if several "alias this"-es have found.
However, in the next situation conflict can be resolved:

struct Test9a
{
    int a;
    alias a this;
}

struct Test9b
{
    int a;
    alias a this;
}

struct Test9
{
    Test9a a;
    Test9b b;
    int c;
    alias a this;
    alias b this;
    alias c this;
}

void test()
{
    Test9 t9;
    int a = t9;
}

When we try to cast Test9 to int we can find several variants: t9.a.a, t9.b.a, t9.c.
However, t9.c is preferred, because Test9 author is explicitly pointed out that Test9 should be converted to int through c field. This magic works only if we have exact match. short a = t9; causes error.

This PR have a one limitation: it doesn't support multiple tuple alias this. It don't clearly understand how them should works. Multiple tuple alias this can be implemented in future in a separate PR.

[IgorStepanov]

Strage bug on Win64. I can't repeat it on Linux64.
I will try to fix it on windows for a few hours. Sorry.

[MetaLang]

If this PR is accepted, you will also be able to claim this bounty: https://www.bountysource.com/issues/1375081-tdpl-there-can-be-only-one-alias-this

[schuetzm]

Timon Gehr suggested opThis as an alternative to alias this, you might want to have a look:
http://forum.dlang.org/thread/xjevtasyafnkvusprldp@forum.dlang.org?page=2#post-ld5c9r:2418lt:241:40digitalmars.com

But this debate was merely about syntax, and I don't see how there there could then be multiple opThis's, because it's not possible to overload on the return type.

[schuetzm]

You write: "This magic works only if we have exact match." However, I think implicitly convertible types should be allowed, too. They work with the current implementation.

The documentation also requires it to be an error if multiple alias this's are eligible. Does your implementation do this?

struct S {
    int i;
    short s;
    alias i this;
    alias s this;
}

S s;
int a = s;       // ERROR: both i and s are eligible
short b = s;     // OK: only s comes into question

[IgorStepanov]

I think implicitly convertible types should be allowed, too. They work with the current implementation.

They allowed, but direct alias this hides base-types aliasthises only if match is exact.
I made a mistake in the above example, but the example of the test is correct:

struct Test9a
{
    short a;
    string b;
    double d;
    alias a this;
    alias b this;
    alias d this;
}

struct Test9b
{
    int a;
    string b;
    alias a this;
    alias b this;
}

struct Test9
{
    Test9a a;
    Test9b b;
    int c;
    alias a this;
    alias b this;
    alias c this;
}

void test9()
{
    Test9 t9;
    t9.a.a = 1;
    t9.a.b = "1";
    t9.b.a = 2;
    t9.b.b = "2";
    t9.c = 3;

    string s = t9; //Wrong: t9.a.b vs t9.b.b conflict
    int a = t9;      // OK. will return t9.c (because t.c is direct alias this and exactly casted)
    long b = t9;   //Wrong: t9.c doesn't exactly casted to long and conflicts with t9.a.a and t9.b.a
    double c = t9; //Wrong.
}

However the next example are works:

struct Test9a
{
    short a;
    alias a this;
}

struct Test9b
{
    short a;
}

struct Test9
{
    Test9a a;
    Test9b b;
    short c;
    alias a this;
    alias b this;
    alias c this;
}

void test9()
{
    Test9 t9;
    t9.a.a = 1;
    t9.a.b = "1";
    t9.b.a = 2;
    t9.b.b = "2";
    t9.c = 3;

    int x = t9; //Ok, because all acceptable aliasthises have a same type (short) and direct aliasthis hides basetypes aliasthises.
}

The documentation also requires it to be an error if multiple alias this's are eligible. Does your implementation do this?

If I don't create mistake, this should works as you say. I'll add it to tests.

[IgorStepanov]

If this PR is accepted, you will also be able to claim this bounty: https://www.bountysource.com/issues/1375081-tdpl-there-can-be-only-one-alias-this

Good news. Thanks =)

[IgorStepanov]

All green. I've moved local struct-member static functions to global scope and it starts to work on windows.

The documentation also requires it to be an error if multiple alias this's are eligible. Does your implementation do this?

Yes, my implementation do it as you say. I've added a corresponding test.

[yebblies]

Please use aliasThisSymbols or something. thises is awkward.

[IgorStepanov]

Ok. Done.

[IgorStepanov]

Ping

[quickfur]

Wow. I have been waiting for this feature for a long time! Can't wait to see this merged. Ping @WalterBright ?

[9rnsr]

@IgorStepanov I'm not reviewing the code yet, but the atXXX functions looks very similar. Can't you merge them?

[IgorStepanov]

I'm not reviewing the code yet, but the atXXX functions looks very similar. Can't you merge them?

Done

[IgorStepanov]

@andralex Ping. Please comment the tests and conflict resolving semantic.

[IgorStepanov]

@andralex ping

[MartinNowak]

I don't see a strong use-case for the ambiguity resolution. So instead of adding a special rule, making the feature/language more complex, I would stick to the existing alias overload = func rule, i.e. it adds a function as overload and ambiguity is a failure.

[MartinNowak]

In C++ there seems to be such a precedence rule for multiple inheritance, but GCC warns about it by default and clang just treats it as error.

[IgorStepanov]

I don't see a strong use-case for the ambiguity resolution.

Example:

struct BigUint
{
   //fields, methods
   @property real getReal();
   alias getReal this;
}

struct BigInt
{ 
   BigUint data;
   int sign;
   //....
   @property real getReal(); same with BigUint.getReal but add a sign to value
   alias getReal this;
   alias data this;
}

struct BigDecimal
{
  BigInt integral;
  uint shift;
   //...
   @property real getReal();
   @property BigInt getBigInt(); //make check, decimal shift and return
   alias getReal this;
   alias getBigInt this;
}

May be this example is not best, but it reflect the idea. Base type declares that it is subtype of T, derived types support this subtyping, but add own behaviour.
Another example: root type in "alias-this"-hierarchy declarrs that it is subtype of PersistentObject.
PersistentObject is a object, which knows how to store another object to DB/file

struct Employee
{
    //
    @property PersistentObject getPO(); // save the Employee fields
    alias getPO this;
}

struct Manager
{
    Employee empl;
    alias empl this;
    //manager-specific data
    @property PersistentObject getPO(); // also save the manager-specific fields
    alias getPO this;
}

struct DB
{
   static void save(PersistentObject);
}
Employee e = ...
Manager m = ...

DB.save(e); //call Employee.getPO
DB.save(m); //call Manager.getPO

[IgorStepanov]

Alias this is more then C++ multiple inheritance. And it can have semantic, different with C++ multiple inheritance.
Anyway, it's not to hard change current behaviour and I call all people to join to disscussion. BTW, in n.g. thread nobody comment or protest against this behaviour. :-(

[schuetzm]

a.a.bar and a.b.bar

[IgorStepanov]

fixed

[IgorStepanov]

@WalterBright @andralex
If you do not go into the fine details, have you fundamental objections aganist this implementation?
I've explained, why I've done so. I have something wrong?

[IgorStepanov]

ping

[deadalnix]

Ping ? I need this. Please @andralex and @WalterBright either merge this or propose actionable items to make this move forward. Right now there is not much to do to have this move forward and that is a problem.

[IgorStepanov]

@andralex AFAIR, you planned to merge this until Jul, 8. Four days remaining:)

[ibuclaw]

Errors shouldn't have any capitals in the message, only symbol names have that privilege. ;)

[ibuclaw]

I agree with @WalterBright and @andralex - there definitely appears to be too much going on, some of which looks like needless noise - such as moving entire functions from expression.c to aliasthis.c with no notable benefit - some of which looks like overcomplicating what should be a modest addition.

When looking around at some of the areas that need changing, I was rather taken aback by the spaghetti code used by the existing alias this implementation. It must be said that the current design is terrible:

Lagain:
    /* 165 lines of code later after checking all other options to resolve the symbol. */
    if (ad && ad->alilasthis)
    {
        e1 = resolveAliasThis(sc, e1);
        goto Lagain;
    }

My feeling is that we must first untangle this unwieldy flow of code, only then will it become a "modest addition".

[IgorStepanov]

@andralex Hello. I was out and will nd I will be absent for some time becauseI'm busy with graduate work at the university and is very busy at the job. I'll return to this work and other D works after a couple of months. Sorry. BTW, I have some ideas about this implementation.

[IgorStepanov]

@yebblies @andralex
Hello. Sorry for a long non-availability.
I plan to start revival of this to February.
As I see, D frontend has been moved from cpp to D since the my last activity.
Have you any suggestion, how I may easy move this PR to D using conversion utilite?
What limitation of a frontend code in D?
Can I use foreach, AA or simple dynamic arrays, phobos?

[schuetzm]

@IgorStepanov Welcome back!

There used to be a script for automatic conversion, but I can't find it anymore. There's also this page on the Wiki about porting PRs to the D version. I guess it's largely no longer relevant now (e.g. magicport.json is gone).

As for which D constructs are allowed: foreach is actually preferred over for, not sure about AAs and dynamic arrays. Phobos however isn't accepted.

[IgorStepanov]

Ok. AA may be usefull if it acceptable.
This (C++) version has a magicport staff. I guess, I need to run magicport manually, get .d files and after that, try to merge with current master.
@yebblies can you write command to do magicporting?

[yebblies]

The procedure in #4922 should work to convert this, once it's rebased onto the last C++ commit using the procedure from the wiki page.

Phobos and the GC are currently being avoided, while some code has been refactored to use foreach. auto and scope delegates.

I would advise doing a direct conversion before any refactoring.

[IgorStepanov]

Thanks. Looks simpler that I expected. Will do it.

[adamdruppe]

How is this going?

[lesderid]

Any update on this?

[wilzbach]

In the State of D survey, this was among the top five missed language features

https://rawgit.com/wilzbach/state-of-d/master/report.html

As this is still based on the C++ frontend, it might take a serious effort to revive it.
Though there's some automation - see #4922 (comment)

[ibuclaw]

This implementation by and large was rejected, as we think that multiple alias this shouldn't be a big change to add support for.

Preliminary PRs may need to be made in order to make the existing alias this support grokable though. Which is probably why this ended up to unwieldy.

[PetarKirov]

Closing as #8378 superseded this PR.