Implement withFilter

[julienrf]

No description provided.

[pnf]

withFilter always seemed to me to be a weird special case. I.e. why would one be concerned about creating a temporary collection when filtering but not anywhere else. Now that we have very lightweight, iterator-based views, wouldn't most uses of withFilter be better rewritten .view.filter....? I suppose I'm also suggesting changing the semantics of for desugaring to use views as much as possible.

[Ichoran]

@pnf - withFilter is a special hint that the contents are ultimately likely to be consumed in full and traversed exactly once. There are cases where this is very valuable information regarding performance. Because for desugaring is not specific to collections, it makes sense to retain this distinction (inasmuch as it ever did). We can implement withFilter as .view.filter, but we shouldn't use the collections rewrite as justification for removing withFilter.

[pnf]

I agree it's a hint that traversal will occur at most once, though I don't see how the probability of complete consumption figures. If anything, it's more valuable to avoid the intermediate when it won't be consumed. I understand that we can't actually get rid of withFilter especially after the recent celebration over requiring it, but the for desugaring could be enhanced to make it easier to be fully lazy. Admittedly it requires type awareness, but @adriaanm's comment in scala/scala#5725 seems to imply there's some openness to extending for-desugaring past the parser stage. We could even do applicatives...

…

On Jul 4, 2017, at 7:22 PM, Ichoran ***@***.***> wrote: @pnf - withFilter is a special hint that the contents are ultimately likely to be consumed in full and traversed exactly once. There are cases where this is very valuable information regarding performance. Because for desugaring is not specific to collections, it makes sense to retain this distinction (inasmuch as it ever did). We can implement withFilter as .view.filter, but we shouldn't use the collections rewrite as justification for removing withFilter. ― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[julienrf]

BTW, do we need FilterMonadic? I’m tempted to say no but maybe it is useful to “mark” that a computation is supposed to be used in for.

[odersky]

@julienrf Out of hand, I don't see a need of FilterMonadic.

Regarding withFilter, this discussion is also relevant: scala/scala3#2573.

If we follow the recommendations there, it would be good to have an empty in each collection (not in the companion object; in the collection itself). If we have that we could change the scheme for for-expression translation and phase out withFilter. All that would happen over time though, right now we definitely need to leave withFilter in. So my remark is about adding empty now, so that we can remove withFilter later.