[Accepted with Modifications] SE-0251: SIMD Additions

The review for SE-0251: SIMD Additions 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 :heart: 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 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

10 Likes

As pointed out by others in the recent generics thread Improving the UI of generics, there is a case where any seems an appropriate keyword. Would this proposal preclude that, or could functions named any be disambiguated from an any keyword in type position?

I was able to make some parse contextually, at least. I wouldn't want to stymie concrete legitimate uses for any as a global function because of a theoretical future language direction in the meantime.

2 Likes

I appreciate the compassion you have toward this accepted proposal, @Joe_Groff. But wouldn’t contextually parsing the some keyword lead to frequent confusion over when a generic vs an existential type is being declared? Correct me if I’m mistaken, but isn’t the whole point of introducing a keyword, like any, to dispel the contextual confusion regarding a protocol used as a type vs a constraint?

To me, giving away the any keyword to what @John_McCall, this proposal’s review manager, admits is “a relatively niche topic” seems a bit premature. Especially when a vision of the potential evolution for the generic and existential systems has just been laid out for the community to digest.

We think there's substantial potential for these names in other DSL-like situations, not just SIMD. And like I said, we really can't steal these as non-contextual keywords because they're somewhat widely used in existing libraries.

2 Likes

Also, we already have capital-a Any as a keyword, and it would syntactically work the way proposed in that other document. I like lowercase some/any for vague aesthetic reasons, but Some/Any could work too.

1 Like

We think there's substantial potential for these names in other DSL-like situations, not just SIMD. And like I said, we really can't steal these as non-contextual keywords because they're somewhat widely used in existing libraries.

I appreciate that there may be potential DSL-like situations in the future, and why there is a strong desire to set a precedent with this proposal. However, I have some concerns about the "somewhat widely used" assertion. For example, what data has been collected to determine how somewhat widely used the any identifier really is? How was the data collected? And what metrics were compared?

It's not my intention to make anyone feel bad by asking these questions. I'm just trying to subtly point out that the addition of any new keyword is going to conflict with some subset of existing libraries. And while I believe it was not intended, it feels very dismissive when someone asserts, without any supporting evidence, that keywords can't be stolen from existing libraries. It feels extra dismissive considering how this proposal aims to introduce global functions, effectively stealing away the identifier in question from the same existing libraries.

Also, we already have capital-a Any as a keyword, and it would syntactically work the way proposed in that other document. I like lowercase some / any for vague aesthetic reasons, but Some / Any could work too.

Agreed, Some and Any could work. Though considering how all other keywords in the language are lowercase (as best as I remember), some and any clearly and contextually indicate that these identifiers are keywords and not types.

Unlike (non-contextual) keywords, function names can be overloaded. Unless existing libraries are defining any<T>(_ v: SIMDMask<T>) -> Bool, nothing has been stolen from them.

1 Like

Unlike (non-contextual) keywords, function names can be overloaded. Unless existing libraries are defining any<T>(_ v: SIMDMask<T>) -> Bool , nothing has been stolen from them.

You're absolutely right; that was a mistake in my logic. Thanks very much for reminding me.

1 Like

I do not know what this proposal is about because I don’t have previous knowledge of the acronyms involved and didn’t take the time to read it. However, I’m commenting just to put in my 2¢ that I quite like the any and some keywords proposed in the recent discussions on generics and the prospect that that may be impossible not because it isn’t the perfect solution but because we planned poorly and made it impossible is demoralizing.