Ian Lance Taylor wrote:
Mark Shinwell <[EMAIL PROTECTED]> writes:
I would now like to propose that the check in that function be made
even stronger such that it disallows conversions between vectors
whose element types differ -- even if an implicit conversion exists
between those element types.
As far as I can see, what that amounts to is saying that there should
not be an implicit conversion between vector of int and vector of
unsigned int. It seems to me that a cast would then be required to
call, e.g., vec_add with arguments of type __vector unsigned int. I
don't see how that is useful.
But perhaps I am mistaken; can you give an example of the type of
thing which is currently permitted which you think should be
prohibited?
Things exactly like what you write above ("an implicit conversion
between vector of int and vector of unsigned int"). My main argument
is that the gcc behaviour seems to be at odds with the semantics
envisaged by the designers of these various vector-based instruction
sets we see around -- and indeed the designers of the STL -- although
perhaps that is a misconception and there are actually many more
examples where it is believed that these implicit conversions are
reasonable.
I don't see a reason _per se_ why having the implicit conversions
is a good thing -- for things such as vec_add, presumably more
alternatives can be added (there are various ones already I see for
differing orders of "vector bool short" / "vector signed short") etc.
I think it is open to debate whether it is a good thing to have to
make those alternatives explicit, or whether some should be filled in
by implicit conversions.
However, this...
Mike Stump wrote:
> My only concern is that we have tons of customers with tons of code and
> you don't have any
That isn't quite true :-)
> and that you break their code.
...is more of a concern, I agree, and is what I worry about most.
Mark
