[swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

[plx]

Late response!

As-specified, although I understand the *motivation* for this suggestion, I can’t support the specific proposal whatsoever.

That said, I do think there’d be a lot of value in a way to add “convenience type predicates” (terrible name, please improve!) to declarations, so that e.g.:

  protocol Sequence {

    // one possibility for a declaration:
    typealias of<E> == S: Self where S.Iterator.Element == E

  }

…would allow you to write your examples like this:

  // sequence-accepting variant
  func doSomething<S:Sequence.of<Foo>>(values: S) { … }

  // hopefully, this would work also:
  func doSomething<C:Collection.of<Foo>>

…either as an extension of the existing generic-typealias syntax or as a separate-but-similar feature.

For the Sequence/Collection it’s a lot of work for IMHO a rather minor convenience, but for more-complex type associated-type relationships it could start to pay its own way.

> On May 24, 2016, at 12:57 PM, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
> 
> One thing that I see a lot in code, and sometimes have to stop myself from doing, is using shorthand array types, such as [Foo], in function declarations where CollectionType could just as easily be used. For example, the following two declarations can take collections of values, but the first will only take them in the form of an Array:
> 
> 	func doSomething(values:[Foo]) { … }
> 	func doSomething<C:CollectionType where C.Generator.Element:Foo>(values:C) { … }
> 
> The latter form is something that new users of Swift tend not to know they can do, and which even experienced Swift developers may not use for the sake of brevity, but it can come up quite a lot. What I’d like to propose is that [Foo], when used in a function, should produce the latter form behind the scenes, requiring the developer to specify Array<Foo> if they actually need it to be an Array for some reason. Though this would become inconsistent with variables/properties which would still have to be Array<Foo> since a type is required.
> 
> 
> An alternative would be if we could specify protocol generics in a more succinct form, for example:
> 
> 	func doSomething(values:Collection<Foo>) { … }
> 	func doSomething(values:Sequence<Foo>) { … } // Many array functions are linear anyway so could just as easily take sequences
> 
> Note: This would not be the same as type-erased wrappers such as AnySequence<Foo>, but rather a shorthand for "Sequence where Generator.Element:Foo"
> 
> 
> 
> In essence I’m hoping to discuss whether we should try to remove the temptation to limit functions to arrays only or not, or if there are other ways to encourage more use of sequence and collection for flexibility; I try wherever possible to have my methods take sequences if they can, and only take collections if they need to (and never arrays only), but I can understand why not everyone does this, as it’s not the friendliest thing to add and declaring [Foo] looks so much neater.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/7a77fba9/attachment.html>