Consider removing splatting from operator overrides

[programmerjake]

Removing splatting from operator overloads would make simd more consistent with the rest of Rust where explicit type conversions are basically always needed, it would also greatly simplify our docs.

Because splatting is so common, we could add a global splat function (wouldn't necessarily replace Simd::splat, but would be otherwise identical) and/or a Splat trait such that you could write my_scalar.splat().

Zulip: https://rust-lang.zulipchat.com/#narrow/stream/257879-project-portable-simd/topic/remove.20splatting.20on.20operators.3F

Related: #195 (comment)
and: #10 (comment)

[workingjubilee]

It is not a great amount of simplification, and having to manually splat everywhere makes reading the resulting code more complicated. Comparing it to the absence of numeric promotion is a false analogy, as the lanewise behavior does not vary, whereas numeric promotion does change lanewise behavior.

[programmerjake]

It is not a great amount of simplification, and having to manually splat everywhere makes reading the resulting code more complicated.

while it may be a little more complex (mitigated by splat fn/trait being short to write), imho consistency and explicitness is waay more important.

Comparing it to the absence of numeric promotion is a false analogy, as the lanewise behavior does not vary, whereas numeric promotion does change lanewise behavior.

That's just cuz your selectively glossing over aspects of the types. imho scalar/vector is a sufficiently important distinction that it should probably not be hidden.

[programmerjake]

From Zulip:
@thomcc:

if we lose autosplatting, i suspect most of the inference errors related to simd in non-simd code will go away too

[programmerjake]

Fixing inference in non-simd code may be the most significant reason to remove splatting, as @workingjubilee mentioned on Zulip

[workingjubilee]

Type inference also "hides" details, and yet we have it, because it's not actually hiding anything if you evaluate something in context, So the ship that Rust should never """hide""" anything on a line-by-line basis has long since sailed. There are other languages which treat their users as if they cannot read anything if it is not written out in triplicate, and I purposefully avoid them.

[Lokathor]

Yeah, not having splatting makes specifically literals a pain in the ass to work with. And we should make them easier to use not worse to use.

[programmerjake]

Yeah, not having splatting makes specifically literals a pain in the ass to work with. And we should make them easier to use not worse to use.

I recognize that, so I think adding splatted literals might be a good idea: 3.5_f32x4 or 3.5_f32x_

[Lokathor]

You would have had me on board if you said something like "let float literals infer into being compiled as a splatted simd value". But if you have to type it all the way out that's very bad. I want core::simd to be so good I throw out the wide crate.

[programmerjake]

hmm, that's an idea i had kinda rejected due to type inference...if you think it'll work i think that'd be a good idea

[Lokathor]

That would be like a whole T-lang MCP->RFC cycle to get done. I don't think we have the bandwidth for that right now honestly.

[programmerjake]

That would be like a whole T-lang MCP->RFC cycle to get done. I don't think we have the bandwidth for that right now honestly.

so, we could use splat as a fallback till then, kinda like try! was