camio / simd-operator-equals-equals

std::simd Objects Should be Value Semantic
Boost Software License 1.0
0 stars 0 forks source link

Comments on P2892R0 #3

Open danieltowner opened 1 year ago

danieltowner commented 1 year ago

Thanks for the interesting paper (P2892R0). I have some comments on it which I think should be addressed to clarify your views.

The paper argues that value types should define operator== to return plain bool, rather than mask. This seems reasonable, but since std::simd doesn't claim to be a value type anyway I don't see why it should have the semantics of value types forced upon it. Before you can claim value-type semantics I I think you need to clearly explain why std::simd is a value type or provide a reference which supports your statement that "std::simd types are value types".

What do you intend to do with other relational operators? Will you define operator< to return bool too, and if so, what is its behaviour? At one point in your paper you mention greater so do you mean to have named functions which return a mask for element-wise comparison? I think seeing the bigger picture of how value-type semantics would affect all relational operators is important.

You state that std::simd::operator== is consistent with the other operators defined in std::simd, and also that std::simd is consistent with existing (element-wise) practice in other simd-wrapper libraries (e.g, VCL, EVE). Can you please clarify what is special about std::simd that it should behave differently (and inconsistently) to existing practice?

camio commented 1 year ago

Value types correspond to entities in the platonic world of mathematical forms. Humans don't decide if something is a value type, something either is or it isn't. And, in this case, a simd type corresponds to a sequence of values. See the reference to EOP for details.

danieltowner commented 1 year ago

True, but humans can choose whether std::simd should behave like that or not. The authors of the SIMD abstractions listed in your paper (EVE, VCL, etc.) have decided that their SIMD wrappers should not be value types, and built the interfaces accordingly. In P0851R0 it is made clear that std::simd is not being treated as a value type. If the accepted industry precedence is that SIMD objects are not value types why should std::simd have to behave as though they are?

camio commented 1 year ago

There's also "industry precedence" that value semantic types are implemented as regular types, but I don't think we should make decisions based only on what others have done. The standard library should be a coherent whole instead of different domains doing things in their own ways. When we are coherent, the benefits of generic programming abound.