Bug 23833 – auto dereferncing does work with alias this

In the following code I would expect the three final lines to equivalent. Currently only the final two compile. ```d struct Int { int val; alias val this; } void main() { Int* x = new Int(123); void foo(int a) {} foo(x); foo(x.val); foo(*x); } ```

The compiler does auto dereferencing only when the lhs of a dot expression is a pointer to an aggregate type (struct, class, interface, union). That does not mean that a pointer is going to always be dereferenced automatically. If that would be the case then that would confuse the overload resolution for situations such as: foo(int a); foo(int* a); Int* x; foo(x); -> ambiguity Of course, a set of rules can be invented to properly implement this, however, the current rules are much simpler to explain: "Whenever the lhs of a dot expression is a pointer to an aggregate type, it will automatically be dereferenced". As such, in your example, `foo(x)` is an error because there is no dot expression involved and type of x is Int*. foo(x.val) works because you have a dot expression and the compiler rewrites to foo((*x).val). foo(*x) works because type Int has an alias this. As such, this bug report is an enhancement request at best, however, most likely it is not going to fly because the current rules are simple and work, whereas what is proposed is going to affect parts of the compiler in serious ways for no apparent benefit. Closing as WONTFIX.

(In reply to RazvanN from comment #1) > The compiler does auto dereferencing only when the lhs of a dot expression > is a pointer to an aggregate type (struct, class, interface, union). That > does not mean that a pointer is going to always be dereferenced > automatically. If that would be the case then that would confuse the > overload resolution for situations such as: > > foo(int a); > foo(int* a); > > Int* x; > foo(x); -> ambiguity > > Of course, a set of rules can be invented to properly implement this, > however, the current rules are much simpler to explain: "Whenever the lhs of > a dot expression is a pointer to an aggregate type, it will automatically be > dereferenced". > > As such, in your example, `foo(x)` is an error because there is no dot > expression involved and type of x is Int*. > > foo(x.val) works because you have a dot expression and the compiler rewrites > to foo((*x).val). > > foo(*x) works because type Int has an alias this. > > As such, this bug report is an enhancement request at best, however, most > likely it is not going to fly because the current rules are simple and work, > whereas what is proposed is going to affect parts of the compiler in serious > ways for no apparent benefit. > > Closing as WONTFIX. Fair enough.