Bug 6083 – [tdpl] There can be only one alias this.

Status
NEW
Severity
normal
Priority
P3
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2011-05-31T15:26:34Z
Last change time
2024-12-13T17:55:23Z
Keywords
bootcamp, bounty, pull, TDPL
Assigned to
No Owner
Creator
timon.gehr
Moved to GitHub: dmd#18344 →

Comments

Comment #0 by timon.gehr — 2011-05-31T15:26:34Z
From TDPL, page 231: "A class could introduce any number of alias this declarations, thus subtyping any number of types." Let's test this: class A{} class B{} class C{ A a; B b; alias a this; alias b this; } Error: alias this there can be only one alias this (I think that error message has a very nice humorous touch!) The same applies to structs.
Comment #1 by issues.dlang — 2011-05-31T17:56:47Z
It's a well-known issue. alias this really isn't fully implemented yet and has lots of bugs to be ironed out. The lack of ability to have more than one alias this is one of them. I'm not sure that there's a bug report on it though, so it's good to have a placeholder for the issue.
Comment #2 by andrei — 2014-01-10T16:40:39Z
The implementation of multiple alias this should lead to semantics that are independent of order, i.e. all `alias this` are tried and if two or more match that's an ambiguity.
Comment #3 by andrei — 2014-01-10T16:42:59Z
Comment #4 by timon.gehr — 2014-01-10T17:33:20Z
(In reply to comment #2) > The implementation of multiple alias this should lead to semantics that are > independent of order, i.e. all `alias this` are tried and if two or more match > that's an ambiguity. A good guideline is to make them behave similarly to imports as far as symbol look-up is concerned.
Comment #5 by destructionator — 2014-02-26T07:42:39Z
I'm not so sure about the ambiguity thing. Consider the following case of a wrapped NotNull!T: interface A { void foo(); } interface B {} class C : A, B { void foo() {} } class D : C {} NotNull!D should implicitly cast to D (a not null is always a maybe null), which gives access to the methods, as well as NotNull!C - classes can always implicitly cast to their base. NotNull!C should implicitly cast to C, NotNull!A, NotNull!B, and NotNull!Object. Now consider we call NotNull!D d = ...; d.foo(); what happens? 1) foo is not a member of NotNull!D, so we try to match the alias thises. 2) D.foo works, so we add that to the ok list. 3) NotNull!C doesn't work, which triggers its list: C.foo also works. Is this an error? C.foo and D.foo refer to the same function, since it is an overridden virtual, but it would compile as both and might be considered ambiguous. However it is implemented, I'd argue it is important that this works since this is one of my main use cases for multiple alias this.
Comment #6 by hsteoh — 2014-12-05T23:13:58Z
Comment #7 by andrei — 2016-10-14T15:39:00Z
I'll bootcamp this as the original author, although well intended, doesn't have the time to push it through completion.
Comment #8 by robert.schadek — 2024-12-13T17:55:23Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18344 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB