I've defined our math classes like so

typedef union Vector4
    {
        public:
            struct _Fields
            {
                public:
                    /**
                     This vector's X coordinate
                    */
                    float X;
                    /**
                     This vector's Y coordinate
                    */
                    float Y;
                    /**
                     This vector's Z coordinate
                    */
                    float Z;
                    /**
                     This vector's W coordinate
                    */
                    float W;
            };

            float Value[4];
            _Fields Fields;

            force_inline float X()
            {
                return Fields.X;
            }

            force_inline float X() const
            {
                return Fields.X;
            }

            force_inline void X(float value)
            {
                Fields.X = value;
            }
            ...
            
    } vec4;

You can however also add an additional field for the 3-component vector if you like, the union should do the trick

Even if the wrapper struct gets optimized away, a large cost remains.

On graphics cards it is a hardware operation, that's part of the appeal. Swizzle and mask operations are effectively free since they were introduced.

On the CPU when “optimized away” the wrappers and completely inlined all the function overhead it is still likely taking 4 floats or 4 pointers in registers, which in turn will affect register coloring and available space plus the cost of indirection is still present in actual processing. Not optimized away it's a variable also taking at least that much space, plus the overhead of the function prolog and epilogs, plus more due to allocations along with the time and space to allocate and destroy.

If you absolutely need it then you'll pay the cost anyway, but know that the cost exists when you start processing long arrays of vertices, point clouds, or point arrays. As the structures can often be processed with SIMD operations for the entire array, in a more serious project you'll likely end up rewriting it for bulk processing anyway. Individual processing one item at a time is quite inefficient.

frob said:
On the CPU when “optimized away” the wrappers and completely inlined all the function overhead it is still likely taking 4 floats or 4 pointers in registers, which in turn will affect register coloring and available space plus the cost of indirection is still present in actual processing. Not optimized away it's a variable also taking at least that much space, plus the overhead of the function prolog and epilogs, plus more due to allocations along with the time and space to allocate and destroy.

That isn't necessarily true. As long as the compiler can inline all functions of the wrapper, then it can reverse-track the references and optimize the storage entirely, by replacing the operation that is done on the wrapper with what the reference points to. I made an simplistic example in Godbolt that shows that the generated assembly could be absolutely identical, from instructions to which registeres are used, as if the wrapper doesn't exist at all, but I lost it overnight (but if you don't belive me I'll recreate it). Now this does depend on the wrapper being created locally in a function, as well as the source of the swizzling being non-conditional, but its possible for this to be 100% free. Though I wouldn't have been able to say whether this is 100% true without looking at the generated assembly, so a bit of caution and measuring here is definately warranted.

hplus0603 said:
It can't possibly do this, because it has storage, and affects aliasing.

Yes, it absolutely can: https://godbolt.org/z/39KMKP1MM​

The function multiplying the vec3 directly, and the one doing the multiply via the wrapper are identical in the generated assembly under O3. As long as you don't store the struct in another class (which, why would you do that when your main goal is to be able to do vec.yz *= 2), optimizing away references and structs containing those is something that a compiler is very capable of doing.

That's solving the wrong problem, really. Quoting myself:

frob said:
the cost exists when you start processing long arrays of vertices, point clouds, or point arrays. As the structures can often be processed with SIMD operations for the entire array, in a more serious project you'll likely end up rewriting it for bulk processing anyway. Individual processing one item at a time is quite inefficient.

If you're processing serious arrays in the same form as HLSL processing millions of entries each frame, but approaching it in a per-point element processing format like this, well … good luck on that.