A big no no for me 
Care to elaborate on why?
1 Like
Strong +1. This was a missing feature for too long and I'm very glad that we finally get it now.
Definitely. It has always been weird that you couldn't extend Array<String> but had to write Array where Element == String instead, especially because it was already possible to extend a typealias StringArray = Array<String>. This therefore removes a big inconsistency in the language and I'm all for it.
For me it definitely does. You can already write Array<String> or even [String] everywhere in Swift, so why would this be the only exception?
Since extensions are quite a unique feature of Swift, I haven't used anything like it in another language before.
I followed the pitch thread closely and fully read the proposal.
It isn't the swift way of coding. We should just leave it this way.
I agree that the basic idea here is squarely in the "obviously it should work this way" category. Being able to use angle brackets rather than a where clause for extension declarations will be a very nice enhancement.
I am not in favor of allowing the sugared spellings like extension [Foo] {. I understand the argument about simplicity. But I actually think that, because the sugared types are so special -- there are only three, and there is no way for a user to add, reuse, or otherwise customize them -- it is simpler and more uniform to disallow them. I think permitting them will make for awkward scanning and reading. The sugared spellings are used widely, but they are not used in this manner, i.e., for top-level declarations. They're used for type annotations and expressions; it's not even possible to use them on the left hand side of a typealias.
Overall I look forward to this being added.
3 Likes
Apparently, your view on what is the swift way of coding is not shared by many people, because a clear majority in this thread seems to be sympathetic with this proposal.
So maybe you need to give some reasons for why it isn't the swift way of coding in your opinion. Otherwise it's quite hard to imagine – at least for me – why one would think that extension Array where Element == String {} is somehow more swifty than either extension [String] {} (I can at least somewhat understand that some people don't like this syntax, even though I'm in favour of it), or extension Array<String> {}, when it literally makes the language more consistent by allowing the same syntax everywhere. In other words, this proposal allows the use of the more swifty syntax (that I consider [String] to be over Array where Element == String) in more places.
2 Likes
They’re allowed to have their opinion, and they don’t have to elaborate on it if they don’t want to.
The Language Workgroup isn’t likely to give it much weight as it is, but nonetheless, they’re entitled to have their say.
3 Likes
Yeah, at which point did I say or imply that they aren't allowed to have their opinion?
I just said that it would be nice if they elaborated on it so that this opinion can be understood by other people, because I really want to understand it.
This is a very sensible proposal. It reduces a point of friction and makes an already implemented feature of extensions more accessible.
It's more like syntactic-splinter-removal rather than syntactic sugar. 
This was my thought too. While I think the rationale in the proposal to require the use of a where clause in such a case would be fine, it does seem like * would be a logical and intuitive option here for an unconstrained type, and feels consistent with the rest of Swift.
This review is now over, and SE-0361 has been accepted.
3 Likes