April 11, 2023 [Issue 23833] auto dereferncing does work with alias this | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23833 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |razvan.nitu1305@gmail.com Resolution|--- |WONTFIX --- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> --- 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. -- |
April 11, 2023 [Issue 23833] auto dereferncing does work with alias this | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=23833 --- Comment #2 from james.gray@remss.net --- (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. -- |
Copyright © 1999-2021 by the D Language Foundation