www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Alias woes

reply SealabJaster <sealabjaster gmail.com> writes:
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
Dec 11 2020
parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
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.
Dec 17 2020
parent reply SealabJaster <sealabjaster gmail.com> writes:
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 :(
Dec 17 2020
parent reply SealabJaster <sealabjaster gmail.com> writes:
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.
Dec 18 2020
parent SealabJaster <sealabjaster gmail.com> writes:
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 :(
Dec 20 2020