www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - CTFE Assignment to anonymous union shows unexpected behavior

reply Rekel <paultjeadriaanse gmail.com> writes:
I'm not sure why this is happening, but after simplifying my code 
I traced it back to what the title may suggest. The original 
cause of my issues being summarized by debug print statements 
returning a union as:

 Mat([nanf, nanF, . . . .], [[1.0F, 0.0F, . . . .])


Even though the nanF should thus be 1.0, 0.0, etc...

This is example code that describes when this happens:

```d
import std.stdio;

struct Apple(uint size) {
	union {
		int[size * size] a;
		int[size][size] b;
	}

	static immutable typeof(this) pie = _pie();
	private static typeof(this) _pie() pure {
		typeof(this) result;
		static foreach (i; 0 .. size)
			static foreach (j; 0 .. size)
				//result.a[i + j * size] = 1; // Works
				result.b[i][j] = 1; // Fails
		return result;
	}
}

void main() {
	Apple!(4) a = Apple!(4).pie;
	writeln(a.a);
	writeln(a.b);
}
```

The working code changes the first integers to 1, the failing 
version keeps them at 0.

What's the reason for this? Logically this doesn't seem 
troublesome to me, and if assigning to non-initial anonymous 
union varialbes isn't possible(?!) that would be pretty bad, and 
I'd be in for quite some trouble in my actual code :(
Apr 22 2021
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Apr 22, 2021 at 10:47:17PM +0000, Rekel via Digitalmars-d-learn wrote:

 I'm not sure why this is happening, but after simplifying my code I
 traced it back to what the title may suggest.


Keep in mind that CTFE does not support reinterpretation via unions,
i.e., reading values from a different field in a union than was
assigned. If you assign field A to a union, then you cannot read field B
from that union in CTFE. You can only do this at runtime, not in CTFE.


T

-- 
There are two ways to write error-free programs; only the third one works.
Apr 22 2021
parent reply Rekel <paultjeadriaanse gmail.com> writes:
On Thursday, 22 April 2021 at 23:41:33 UTC, H. S. Teoh wrote:

 On Thu, Apr 22, 2021 at 10:47:17PM +0000, Rekel via 
 Digitalmars-d-learn wrote:

 I'm not sure why this is happening, but after simplifying my 
 code I traced it back to what the title may suggest.


 Keep in mind that CTFE does not support reinterpretation via 
 unions, i.e., reading values from a different field in a union 
 than was assigned. If you assign field A to a union, then you 
 cannot read field B from that union in CTFE. You can only do 
 this at runtime, not in CTFE.


 T


I'm not sure what you mean,
do you mean if i were to read the field during CTFE, or even if i 
read the field during runtime after initializing it using CTFE?
Apr 22 2021
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Apr 22, 2021 at 11:44:51PM +0000, Rekel via Digitalmars-d-learn wrote:

 On Thursday, 22 April 2021 at 23:41:33 UTC, H. S. Teoh wrote:

 On Thu, Apr 22, 2021 at 10:47:17PM +0000, Rekel via Digitalmars-d-learn
 wrote:

 I'm not sure why this is happening, but after simplifying my code
 I traced it back to what the title may suggest.


 
 Keep in mind that CTFE does not support reinterpretation via unions,
 i.e., reading values from a different field in a union than was
 assigned. If you assign field A to a union, then you cannot read field B
 from that union in CTFE. You can only do this at runtime, not in CTFE.




[...]

 I'm not sure what you mean,
 do you mean if i were to read the field during CTFE, or even if i read
 the field during runtime after initializing it using CTFE?


If you read the field during CTFE.  I've never tested initializing a
union in CTFE then reading it at runtime, though. Not sure exactly what
would happen in that case.


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for
Volkswagen.
Apr 22 2021
parent Rekel <paultjeadriaanse gmail.com> writes:
On Friday, 23 April 2021 at 00:55:50 UTC, H. S. Teoh wrote:

 [...]
 If you read the field during CTFE.  I've never tested 
 initializing a union in CTFE then reading it at runtime, 
 though. Not sure exactly what would happen in that case.


 T


I'm not referring to reading non-initial variables, though Im 
surprised that's not possible?
In any case, it seems assigning values doesn't work during CTFE 
either ... And that is very disappointing to me to be quite 
honest...

This only seems to happen when I use CTFE to create a static 
singleton of the union by assigning to non-initial variables, I 
couldn't find anything in the docs that say I shouldn't, I might 
have missed something...
I really hope this is a bug... if its not, & assuming its not 
inevitable, this really shouldn't be a thing. Be it by design or 
limitation.
Apr 23 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 22 April 2021 at 22:47:17 UTC, Rekel wrote:

 I'm not sure why this is happening, but after simplifying my 
 code I traced it back to what the title may suggest. The 
 original cause of my issues being summarized by debug print 
 statements returning a union as:

 [...]


 Even though the nanF should thus be 1.0, 0.0, etc...

 [...]


This actually seems to be a bug related to order of declaration.

Try this

---
union
     {
         int[size][size] b;
         int[size * size] a;
     }
---
Apr 23 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 23 April 2021 at 10:36:40 UTC, Imperatorn wrote:

 On Thursday, 22 April 2021 at 22:47:17 UTC, Rekel wrote:

 I'm not sure why this is happening, but after simplifying my 
 code I traced it back to what the title may suggest. The 
 original cause of my issues being summarized by debug print 
 statements returning a union as:

 [...]


 Even though the nanF should thus be 1.0, 0.0, etc...

 [...]


 This actually seems to be a bug related to order of declaration.

 Try this

 ---
 union
     {
         int[size][size] b;
         int[size * size] a;
     }
 ---


Lol, formatting. But u get the idea *very* clearly at least 😅
Apr 23 2021
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/22/21 6:47 PM, Rekel wrote:

 I'm not sure why this is happening, but after simplifying my code I 
 traced it back to what the title may suggest. The original cause of my 
 issues being summarized by debug print statements returning a union as:

 Mat([nanf, nanF, . . . .], [[1.0F, 0.0F, . . . .])


 Even though the nanF should thus be 1.0, 0.0, etc...
 
 This is example code that describes when this happens:
 
 ```d
 import std.stdio;
 
 struct Apple(uint size) {
      union {
          int[size * size] a;
          int[size][size] b;
      }
 
      static immutable typeof(this) pie = _pie();
      private static typeof(this) _pie() pure {
          typeof(this) result;
          static foreach (i; 0 .. size)
              static foreach (j; 0 .. size)
                  //result.a[i + j * size] = 1; // Works
                  result.b[i][j] = 1; // Fails
          return result;
      }
 }
 
 void main() {
      Apple!(4) a = Apple!(4).pie;
      writeln(a.a);
      writeln(a.b);
 }
 ```
 
 The working code changes the first integers to 1, the failing version 
 keeps them at 0.
 
 What's the reason for this? Logically this doesn't seem troublesome to 
 me, and if assigning to non-initial anonymous union varialbes isn't 
 possible(?!) that would be pretty bad, and I'd be in for quite some 
 trouble in my actual code :(


I think this is a bug. For sure, the only 2 valid options are, it should 
compile and do what you are expecting, or not compile.

CTFE unions are (I think) implemented as a "tagged" union, where only 
one value is set. When you assign to a *part* of b, you are assigning to 
something that isn't being used.

Normally, in CTFE, using a union member that isn't set is an error 
(compile-time because CTFE).

If you assign to b all at once, it works:


```d
     private static typeof(this) _pie() pure {
         typeof(this) result;
         typeof(b) val;
         static foreach (i; 0 .. size)
             static foreach (j; 0 .. size)
                 val[i][j] = 1;
         result.b = val;
         return result;
     }
```

I think the compiler is allowing the usage of a part of b without the 
tag being updated. Probably the right answer is, setting an element of b 
should be an error, or it should switch the tag (if the union was never 
set).

BTW, I think the fact that the union members are arrays is important. 
Please file a bug.

-Steve
Apr 23 2021