# Pitch: Efficient \`Collection.startIndex\` throughout the standard library

**URL:** <https://forums.swift.org/t/pitch-efficient-collection-startindex-throughout-the-standard-library/45317>\
**Category:** Pitches\
**Created:** [March 4, 2021, 5:37pm UTC](https://forums.swift.org/t/pitch-efficient-collection-startindex-throughout-the-standard-library/45317 "2021-03-04T17:37:18Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [March 11, 2021, 7:58pm UTC](https://forums.swift.org/t/pitch-efficient-collection-startindex-throughout-the-standard-library/45317/6 "2021-03-11T19:58:31Z")

</div>

> [@timv](#):
>
> Thanks for raising this concern, this is definitely good to keep in mind when adding new types and deprecating the old ones.

I think generic value parameters have kind of gone a bit under-the-radar next to variadic generics, which are much sexier, but they would give us tremendous capabilities for any kind of wrapper which includes a closure. As things stand, you can get significantly better, more efficient wrappers than any general-purpose type by copy/pasting the implementation and swapping the closure for a function. In a project I'm working on, I did this with `LazyFilterCollection` and saw enormous performance improvements (I assume because the compiler didn't need to retain a closure, and generic specialisation told it exactly what the filter predicate was, so it could inline it and optimise around it).

> **Just re-ran my benchmarks**
>
> ```swift
> benchmark column baseline latest %
> ---------------------------------------------------------------------------------------------
> Constructor.SpecialNonFile.AverageURLs filtered std 31.94 22.33 30.09
> Constructor.SpecialNonFile.AverageURLs filtered iterations 20704.00 5217.00 74.80
> Constructor.SpecialNonFile.AverageURLs filtered time 59565.00 250315.00 -320.24
> ...
> Constructor.SpecialNonFile.IPv4 host filtered std 33.79 40.77 -20.64
> Constructor.SpecialNonFile.IPv4 host filtered iterations 26756.00 8477.00 68.32
> Constructor.SpecialNonFile.IPv4 host filtered time 46838.00 154797.00 -230.49
> ...
> Constructor.SpecialNonFile.IPv6 host filtered std 29.79 28.72 3.62
> Constructor.SpecialNonFile.IPv6 host filtered iterations 22074.00 7611.00 65.52
> Constructor.SpecialNonFile.IPv6 host filtered time 57169.00 168267.00 -194.33
> 
> ```
> 
> "baseline" is using my copy/pasted lazy-filter, "latest" is using the standard library's one. It's anywhere from ~200% to 300% slower to use the standard library.

I'm not sure how widely-known this issue is, or how the core team rates its severity. Personally I think it is more pressing than variadic generics, such that it's probably worth holding off on touching the lazy collections until they can be fixed.

As a bonus, generic value parameters would mean we can finally make `@lazy` a property wrapper, without having to actually store a closure inside of it.

---

_[View the full topic](https://forums.swift.org/t/pitch-efficient-collection-startindex-throughout-the-standard-library/45317)._
