Please see this shortened snippet: https://godbolt.org/z/j8f3x5

I've ran into annoyances before when using aliases to member fields, but something subtle like this was rather annoying to figure out.

Why does the compiler feel the need to embed a context pointer anytime you provide an to alias a member?

In my case the function was also writing seemingly garbage values into the .ptr and .length fields for the ref'd string, but it doesn't seem to happen in the godbolt snippet.

Bonus, a pet peeve of mine: https://godbolt.org/z/bnK91f

On Saturday, 12 December 2020 at 01:02:56 UTC, SealabJaster wrote:
> Please see this shortened snippet: https://godbolt.org/z/j8f3x5
>
> I've ran into annoyances before when using aliases to member fields, but something subtle like this was rather annoying to figure out.
>
> Why does the compiler feel the need to embed a context pointer anytime you provide an to alias a member?
>
> In my case the function was also writing seemingly garbage values into the .ptr and .length fields for the ref'd string, but it doesn't seem to happen in the godbolt snippet.
>
> Bonus, a pet peeve of mine: https://godbolt.org/z/bnK91f

I don't have an answer, but aliasing non-static fields outside the struct isn't something one does often. This is probably a bug.

On Thursday, 17 December 2020 at 21:10:20 UTC, Q. Schroll wrote:
> I don't have an answer, but aliasing non-static fields outside the struct isn't something one does often. This is probably a bug.

At least it wasn't just me overlooking something.

If it is a bug, I wonder which part of it is buggy. The random context pointer being inserted? The 'function' being assignable to a function variable? Both?

I'm personally leaning on the assignment being a bug at the very least, since the compiler really should be stopping that from happening.

As for the context pointer I'm going to just assume there's a reason it's there in the first place. I'm 50/50 about it.

Hopefully someone with more know-how will see this and explain :(

On Thursday, 17 December 2020 at 22:06:00 UTC, SealabJaster wrote:
> ...

Well, at least I understand why the context pointer exists now.

If you were to add a `pragma(msg, __FUNCTION__)` into either of the templated functions, you'd get the following output.

```
example.C.doShizz!(a).doShizz
example.C.staticShizz!(a).staticShizz
```

Where `example` is likely the name of the module in Godbolt.

But then there's the `.C.` part, which is the parent type for the alias being passed into the templated functions.

So essentially, the compiler is rewriting `doShizz!(C.a)` as something like?:

```
struct C
{
    int a;

    template doShizz(alias T = a)
    {
        void doShizz(ref string a){...}
    }
}
```

Weird, and annoying. Especially since the compiler still allows it to be a function instead of a delegate.

On Saturday, 19 December 2020 at 07:41:09 UTC, SealabJaster wrote:
> ...

The nesting behavior is indeed intentional: https://dlang.org/spec/template.html#implicit-nesting

But I still assume the assignment to a function is also a bug, so I'll file that if it hasn't been already (unless for some very strange reason it's not a bug?).

Still though, this is very annoying behavior when you consider an example such as: https://godbolt.org/z/9nWWxa

Alas :(