[cfe-dev] Matrix Support in Clang

[John McCall via cfe-dev]

On 2 Apr 2020, at 16:17, Florian Hahn wrote:

> > On Apr 2, 2020, at 17:32, John McCall <rjmccall at apple.com> wrote:
>>
>> On 2 Apr 2020, at 9:47, Florian Hahn wrote:
>>
>> On Apr 1, 2020, at 20:48, Stephen Canon <scanon at apple.com> wrote:
>>
>> On Apr 1, 2020, at 1:23 PM, John McCall via cfe-dev 
>> <cfe-dev at lists.llvm.org> wrote:
>>
>> On 1 Apr 2020, at 13:15, Florian Hahn wrote:
>> I agree that ideally we would not allow mis-matched binary operations 
>> to avoid surprises. It looks like the existing vector type does not 
>> perform implicit conversion for binary operations with 2 vector 
>> operands (unless the there is a type mis-match and the data size 
>> matches, then the LHS type is chosen). For binary ops with vector and 
>> scalar operands, the scalar operand is converted to the vector 
>> element type. So short4 + short4 -> short4, short4 + int -> short4, 
>> short4 + int4 -> invalid.
>>
>> Given that precedence, I think we should opt for not providing 
>> conversions for binary operators with two matrix operands. For the 
>> matrix and scalar versions, we could convert to the element type 
>> automatically for convenience. But at that point, the gain is 
>> probably quite small and it would be simpler to don’t do 
>> conversions in any case. Does that sound reasonable?
>>
>> I think converting scalars is a necessary convenience in C given that 
>> e.g. literals are normally of type int, but yes, I think it’s fine 
>> to not implicitly convert matrices as long as you have a way to 
>> convert them explicitly.
>>
>> Converting them explicitly should be covered by the standard 
>> conversion rules, right?
>>
>> Do you want matrices to be implicitly convertible in non-operator 
>> contexts? Like, if you assign a float4x4 to an int4x4, should that 
>> implicitly convert the elements or be ill-formed?
>>
>>
> I think the current formulation allows for implicit conversions for 
> matrixes.
>
> But given the recent changes in the arithmetic context, it might be 
> better to only allow explicit conversions. Having implicit conversions 
> for non-operator contexts and not in operator contexts seems a bit 
> inconsistent. I think we should keep the conversion rules based on the 
> element types, but limit them to explicit conversions. Does that make 
> sense?\

That makes sense to me.  If it’s actually a usability issue in 
practice, we can revisit, but I suspect that if we start strict we’ll 
avoid that.

John.