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
