[swift-evolution] [Pitch] Retiring `where` from for-in loops

[L. Mihalkovic]

Regards
(From mobile)

> On Jun 14, 2016, at 7:01 AM, Charlie Monroe <charlie at charliemonroe.net> wrote:
> 
> 
>> On Jun 13, 2016, at 9:59 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> 
>>>> See the benchmarks me and Erica have posted here a few days back - even with the lazy accessor, if you decided to use filter(_:), you lost 10+% of performance. Correct way to do this without `where` and without performance penalization is to use guard within the for-in loop.
>>> 
>>> 10% on a microbenchmark repeater 4000000 times is hardly a justification for going on way or the other.
>> 
>> You're right: 10% on a microbenchmark isn't the best possible data. If you have better data, we are all ears.
> 
> I never said that it's a deal-breaker, but it is definitely something to consider. Since we're discussing performance of the loop itself, you can't perform much in the body of the for loop since it would skew the result (obviously). 

This is a potentially very questionable statement as it stands!  Rule #1 of micro benchmarking is: they measure something for sure, but do you know what? Unless you do understand your compiler and how to make it do what you want, micro-benchmarks should always be assumed to be a misleading waste of time. If however you manage to convince yourself that what you measure is what your think you are measuring, then they can be a useful tool (disassembling is a good starting point).

Benchmarks like that should be considered wit their use-case. The numbers (provided they can be validated) would indicate that the difference is negligeable altogether. And someone doing heavy math would hopefully use accelerate for vectorization, rather than code like this.

> 
> I've previously noted that if/guard-continue come in really close speed-wise, which makes them candidates for a fix-it in case `where` is indeed removed.
> 
> My response here was solely to Jean-Daniel's note that he mustn't forget to include the lazy accessor, pointing out that even the lazy accessor is slower than using an inline check.
> 
> 
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>