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@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution