Delegate parameter name shadows type name

[H. S. Teoh via Digitalmars-d-learn]

On Mon, Jan 09, 2017 at 11:18:02AM -0800, Ali Çehreli via Digitalmars-d-learn wrote:
[...]
> // Some type of the API
> struct MyType {
>     int i;
> }
> 
> // Some function of the API that takes a delegate
> void call(void delegate(MyType) dlg) {
>     dlg(MyType(42));
> }
> 
> void main() {
>     /* The programmer simply copied the delegate definition from
>      * the function and used it as-is when passing a lambda: */
>     call(delegate void(MyType) {

Are you sure this isn't spelt `void delegate(MyType)`?


>             /* WAT? Does the following really compile? After all,
>              * MyType.i is NOT a static member! */
>             if (MyType.i == 42) {
>                 // ...
>             }
>         });
> }
> 
> I was surprised to see it compiled and worked but of course MyType at
> the lambda definition inside main() is not a type name, rather the
> parameter name. Surprising, but I think this is according to spec.
[...]

I think it makes sense relative to your rationalization of it per the
spec, but from an objective POV, I think it rightly deserves a WAT?.
I can't see anything useful such a construction would allow, besides
leading to buggy code caused by unexpected shadowing.

I'd say file an enhancement request to make such code a compile error.


T

-- 
Ph.D. = Permanent head Damage