[swift-evolution] [Pitch] Improve `init(repeating:count)`

[Tony Allevato]

On Thu, Aug 17, 2017 at 9:20 AM Ross O'Brien <narrativium+swift at gmail.com>
wrote:

> (0..<3).map{ _ in UIView() } - map already returns an Array.
>
> Array((0..<3).map{ _ in UIView() }) is redundant.
>

Ah, right, thanks for pointing that out. I couldn't remember off the top of
my head whether it returned an array or some kind of special sequence type
that would need to be converted over.

In that case, I still think the map version wins—it's very clear that a
repeated *operation* is occurring, whereas the originally proposed
@autoclosure version hides that very important semantic information.


I've fallen foul before, of trying to create an array of six buttons and
> getting an array of one button six times; I think that should be easier.
> But if each button corresponds to an existing value or needs to be
> initialised based on its index in that array, map transposing values or
> indices into buttons is already covered.
>
> On Thu, Aug 17, 2017 at 5:03 PM, Tony Allevato via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Couldn't this be rewritten more simply today as:
>>
>>     Array((0..<3).map { index in MyView(forIndex: index) })
>>
>> And the version that doesn't need the index could be written:
>>
>>     Array((0..<3).map { _ in UIView() })
>>
>> The AnyIterator approach posted above is also nice—I wouldn't have
>> thought of that one. But I suppose that only works in the case where you
>> don't need the index.
>>
>> So the question is, should we increase the API surface of Array for
>> something that (IMO) is already fairly straightforward to do? The nice
>> thing about the approaches above is that they're composable. Array doesn't
>> have to make any assumptions about closures or index arguments to those
>> closures; it just takes a sequence and we already have primitives to
>> construct sequences of new objects using .map. Array(repeating:count:) and
>> repeatedElement(_:count:) are nice when the value being repeated is fixed,
>> but I think once you start getting into questions like "what if I need a
>> different thing each time?" or "what if I need to involve the index as part
>> of the elements?" then it's better suited to compose the features already
>> there to build something up than to add new APIs that try to cover each of
>> these special cases.
>>
>>
>> On Thu, Aug 17, 2017 at 8:40 AM Christopher Kornher via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> We might as well add the index to the call so elements can be created
>>> from other lists, etc.
>>>
>>>  Array(repeatedlyCalling: { (index:Int) in MyView( forIndex:index ) },
>>> count: 3) // This might by syntactically correct...
>>>
>>>
>>>
>>> On Aug 17, 2017, at 9:24 AM, Rob Mayoff via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> On Thu, Aug 17, 2017 at 7:04 AM, Robert Bennett via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> Alternatively, instead of replacing the current definition with an
>>>> autoclosure version, we could leave the current version in place and add a
>>>> version taking a function. This could be especially useful when you’ve
>>>> defined a function like `makeMySpecialKindOfButton() -> UIButton` that does
>>>> a lot of customization to an object before returning it.
>>>>
>>>> Array(repeating: { return UIView() }, count: 3)
>>>> and
>>>> Array(repeating: makeMySpecialKindOfButton, count: 3)
>>>>
>>>
>>> This is still source-breaking, because an array of closures is legal. We
>>> need a different name to avoid breaking source:
>>>
>>>     Array(repeatedlyCalling: { UIView() }, count: 3)
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> 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/20170817/64f684a7/attachment.html>