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