Simd vector types

[Chris_Lattner3 (Chris Lattner)]

@scanon

This is, in effect, an argument that the "core" operators should not actually be overloadable, because we don't want to adversely impact the type checker. I guess that's a somewhat pragmatic position, but to me it seems silly to put nice semantic features into a language and then turn around and say "but you can't actually use them".

No, it argues that they should be overloadable but that overloads shouldn't change the type signatures. I have been outspoken about this.

Separate from the "mistakes that have been made in the past", we have the more pertinent question of "should we make a new decision that we know will impact type checker performance. I think the answer is clearly "no".

@scanon

We already have precedent for introducing variants of operators with the + vs +& operator family. I'd suggest introducing a sigil for "vector comparisons that return a vector", producing something like <~ or whatever (but pick any other evocative operator character in place of ~ :-) the advantage of doing this is that we'd be carving off lexical space to think and talk about vectors which IMO is a really good thing.

I'm much more sympathetic to this line of argument, but I note that there is considerable precedent for "just" using the normal comparison and arithmetic operators: Metal, OpenCL, Matlab, Python (Numpy), C and C++ with clang/gcc vector extensions, Fortran, all use the "normal" operators.

The only real precedent I know of for doing anything else is Julia, who use . -prefixed operators for all elementwise operations (and Matlab, which does the same only for multiplication). I'm personally pretty OK with this convention. It's terse enough, there's just enough precedent for it, and if you squint the . s mostly disappear and you're left with something readable.

I was under the impression, though, that you all really wanted to use * for the element-wise product in Swift/TF. If we adopt the Julia convention, I assume that would be expressed as .* , leaving * for the dot / matrix product.

I'm not motivated by the "what other languages do" argument. I'm motivated that we need to make this easy/compact to express, and I stand by the line that we should make different operators be different. In this case, not only is vector-returning comparisons substantially different than every comparison that exists, but you're proposing supporting BOTH semantics in the same type and have them disambiguated based on return type inference.

This is bad for a whole bunch of reasons, including the fact that simple things like let x = v1 < v2 won't type check, that expressions in generic contexts will generate truly crazy error messages, and the fact that someone reading the code will have a hard time understanding that a non-standard notion of comparison is in play.

When we introduced the +& and ..< operators we discussed the principles of this at length, and agreed that it is best to make unfamiliar concepts have unfamiliar spelling, so you at least know that you don't know what is going on.

All that said, your point about Julia is a good one. We should probably spell these comparison operators as .== or ==. to say they produce "pointwise" results. I don't think there is any need to change * to *. though, since your proposal maintains the invariant that the result and operands have the same type.

-Chris