# \[Accepted with Modifications\] SE-0251: SIMD Additions **URL:** \ **Category:** Announcements\ **Created:** [April 8, 2019, 3:03am UTC](https://forums.swift.org/t/accepted-with-modifications-se-0251-simd-additions/22801 "2019-04-08T03:03:12Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\ **Post date:** [April 8, 2019, 3:03am UTC](https://forums.swift.org/t/accepted-with-modifications-se-0251-simd-additions/22801/1 "2019-04-08T03:03:13Z")
The [review](https://forums.swift.org/t/se-0251-simd-additions/21957) for [SE-0251: SIMD Additions](https://github.com/apple/swift-evolution/blob/master/proposals/0251-simd-additions.md) ran through April 1st. There was very little formal feedback in the review. SIMD is a relatively niche topic, and this is a relatively rarefied extension to the SIMD APIs, so it's unsurprising that most people didn't feel any need to express an opinion about it, and that's fine. However, as a frequent review manager, I'd like to encourage people who _do_ have an opinion about a proposal to always write at least _some_ formal feedback on it; even something as basic as a "+1" in the review thread provides a much clearer signal than, say, clicking ❤ on the review post, or only commenting in the thread to try to answer objections raised by other people's reviews. Feedback was generally positive overall, but each review expressed some reservations about various parts of the proposal. Many of those reservations were addressed within the thread, and the Core Team agrees with those responses. The proposal author agrees that there's no need to special case the swizzles on `SIMD3`, so those clauses will be struck from the proposal. The principal remaining objection is to the addition of `any` and `all` to the global namespace; the Core Team agrees with this addition, but we'd like to explain our reasoning in a bit more detail. It is a primary goal of Swift to support fluent and expressive libraries. The [API design guidelines](https://swift.org/documentation/api-design-guidelines/) are explicit that the highest priority in library design is _clarity at the point of use_. Consistency is only a means to that end, not a goal in itself. In many cases, using a uniform language construct like method calls to spell an API is good design because the consistency contributes to clarity: programmers already understand how method calls work, and method calls combine naturally with features like optional chaining instead of requiring circumlocutions that would harm the overall clarity of the code. But `any` and `all` will often be used directly on the result of a binary comparison, making a method call awkward and harder to read, and they will often by used directly as `if` conditions and rarely in conjunction with optional chaining. In this case, the Core Team feels that a more "DSL-like" approach like that proposed for `any` and `all` creates an overall more fluent API. The Core Team also considered that this use of `any` and `all` will likely prevent their future use as keywords. However, claiming these identifiers as keywords would already cause problems with a fair amount of existing code, and it's far from clear that these would be the best choices for keywords in any event. Accordingly, SE-0251 is **accepted** with the **modification** that the special cases for `SIMD3` swizzles be struck. As always, thank you for helping to make Swift a better language. John McCall Review Manager --- _[View the full topic](https://forums.swift.org/t/accepted-with-modifications-se-0251-simd-additions/22801)._