SE-0229 SIMD, migration process plans?

Evolution Discussion
1

(If my below examples (that involve frameworks like Accelerate and SceneKit) are off-topic, perhaps the main question can be answered anyway.)

Now that SE-0229 SIMD has been accepted with modifications, I'd like to know if there are any plans for what the migration process will be like (from existing "import simd"-types, eg float3 to the new SIMD3<Float>). I did a quick search of the forums (review thread here) but couldn't find anything mentioned about it.

For example:

The current "import simd"-types are integrated in eg Accelerate, and the SceneKit documentation advices us to:

Important
In macOS 10.13, iOS 11, tvOS 11, and watchOS 4 (or later), use data types provided by the system SIMD library (such as float3 and float4x4) and the corresponding SceneKit methods (such as simdPosition and simdTransform) instead. These types provide faster performance, offer more concise C, C++, and Swift syntax (such as + and * operators instead of functions), and interoperate better with other technologies (such as Model I/O, GameplayKit, and the Metal Shading Language).

So when the new SIMD vector types have landed, will eg float3 continue to live on the side of SIMD4<Float>, and if so, will they be bridged in some way?

Will eg SceneKit's SCNNode's current
simdPosition: float3
be changed to
simdPosition: SIMD4<Float>?
and if so, what will the types of its simdOrientation and simdPivot properties be?

Similar questions can be asked with regards to Accelerate.

2

As part of the changes for SE-0229, float3 is now a typedef of SIMD3<Float>. The name float3 won't go away for source compatibility reasons, but I expect it to be deprecated eventually in favor of the new naming.

1 Like
3

(EDIT: I guess this means that the new SIMD3<Float> will have to have the unfortunate conformance to Collection that float3 has.)

And what about eg float4x4 and simd_quatf?

4

The new SIMD types do not conform to Sequence or Collection. That was an explicit design decision.

IMO, it is however worth exposing a Collection view of the contents, for interaction with other generic code (taking the Array.init<S: Sequence>(_: S) initialiser as a trivial example). But that wasn't part of the proposal and is something for consideration in the future.