April 11, 2023
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
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.

--