Unclear specification for __swizzle_vec__ type

[gmlueck]

This question arose from a discussion with our DPC++ implementation team. The following statement in section 4.14.2.4 "Swizzled vec class" is unclear:

The __swizzled_vec__ class template should return __swizzled_vec__& for each operator inherited
from the vec class template interface which would return vec<DataT, NumElements>&.

Is this intended to apply to all the hidden friend functions of vec that are operators? For example, consider this operator:

friend vec operator+(const vec& lhs, const vec& rhs);

Is the spec saying that __swizzled_vec__ should define a hidden friend like this:

friend __swizzled_vec__ operator+(const __swizzled_vec__& lhs, const __swizzled_vec__& rhs);

What about other combinations of arguments, such as the ones below? Is the spec saying they should be defined also?

friend __swizzled_vec__ operator+(const __swizzled_vec__& lhs, const vec<DataT, NumElements>& rhs);
friend __swizzled_vec__ operator+(const vec<DataT, NumElements>& lhs, const __swizzled_vec__& rhs);

In addition, it's unclear what the effect of this operator should be. The __swizzled_vec__ class is supposed to represent the result of a swizzle operation before the operation is actually performed. Therefore, does this operator+ return a __swizzled_vec__ that also represents the addition without actually performing the addition?

This all seems like a lot of guesswork based on a terse statement in the spec. If this is really what we intend, it seems like the spec should state this more explicitly.

[gmlueck]

It was pointed out to me that the spec sentence I quote above:

The __swizzled_vec__ class template should return __swizzled_vec__& for each operator inherited
from the vec class template interface which would return vec<DataT, NumElements>&.

applies only to the operators that return a vec reference. Therefore, my example using operator+ is not correct. I think the intent of the spec is that the __swizzled_vec__ version of operator+ should return vec (not __swizzled_vec__). The spec is not clear about the types of the operands, but I presume we want to provide these overloads:

friend vec<DataT, NumElements> operator+(const __swizzled_vec__& lhs, const __swizzled_vec__& rhs);
friend vec<DataT, NumElements> operator+(const __swizzled_vec__& lhs, const vec<DataT, NumElements>& rhs);
friend vec<DataT, NumElements> operator+(const vec<DataT, NumElements>& lhs, const __swizzled_vec__& rhs);
friend vec<DataT, NumElements> operator+(const __swizzled_vec__& lhs, const DataT& rhs);

The sentence I quote does apply to the assignment operators like operator+=, though. I think it is saying that the implementation should provide these overloads:

friend __swizzled_vec__& operator+=(__swizzled_vec__& lhs, const __swizzled_vec__& rhs);
friend __swizzled_vec__& operator+=(__swizzled_vec__& lhs, const vec<DataT, NumElements>& rhs);
friend __swizzled_vec__& operator+=(__swizzled_vec__& lhs, const DataT& rhs);

I think it is still unclear what the effect of these operators should be. Does the returned __swizzled_vec__ represent the addition without actually performing the addition? (See my commentary in the original description of this issue.)

Although the spec does not say this, I presume we would also want this overload, which returns vec (not __swizzled_vec__):

friend vec<DataT, NumElements>& operator+=(vec<DataT, NumElements>& lhs, const __swizzled_vec__& rhs);

[gmlueck]

After chatting with @AerialMantis, I think I understand the intent better. Part of my confusion was with this statement in the spec:

Both kinds of swizzle member functions must not perform the swizzle operation themselves, instead the swizzle operation must be performed by the returned instance of __swizzled_vec__ when used within an expression, meaning if the returned __swizzled_vec__ is never used in an expression no swizzle operation is performed.

I interpreted that to mean that __swizzled_vec__::operator+= does not actually modify the vec and that the + operation is somehow represented by the __swizzled_vec__ that is returned. But, now I think this is a wrong interpretation.

I now think our intent with that sentence was to say that __swizzled_vec__ is a view of the underlying vec object, where the view shows the effect of the swizzle. Furthermore, I think our intent was that assignment operations like += do modify the underlying vec by adding to the elements that are selected by the swizzle.

My conversation with @AerialMantis also confirmed that the spec should clarify that the __swizzled_vec__ hidden friend functions should include the various overloads I show above.

I am preparing a PR to help clarify these things in the spec.

[gmlueck]

See #514 for my attempt to clarify this.