[swift-evolution] Reduce with inout

[Tony Allevato]

On Wed, Jan 18, 2017 at 10:33 AM Guillaume Lessard via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On 18 janv. 2017, at 10:21, Joe Groff via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> >> On Jan 18, 2017, at 2:11 AM, Chris Eidhof via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> If stressing the type-checker is the only problem, then maybe we should
> improve the type-checker, instead of placing that burden on every user of
> the language.
> >
> > That's a nice sentiment, and there's certainly a lot of work we have yet
> to do on the type checker to make it generally better. Higher-order
> functions like `reduce` naturally chain into larger expressions, though,
> and having such a fundamental sequence operation drag down the type-checker
> every time you use it would be unfortunate if we can avoid overloading the
> name.
>
> Empathy for the compiler is nice, too, but users and developers are more
> important. Given that, it seems to me that the default option should be to
> overload the function, unless the alternative is actually clearer.
>

Empathy for users and developers is important, but if the solution adds too
much burden to the type checker and blows up your compile time or gives you
"expression too complex to be solved" errors, then users/developers don't
benefit at all from that either. I don't think it would have been brought
up if there weren't significant concerns about how such an overload would
affect build time or ability to complete. (One of my code bases really
pushes the type checker to its limits and I can sympathize with the
concern.)



> In the spirit of comparing burdens, how much more compilation time would
> be spent if `reduce` is overloaded? How much execution time would be saved
> by users thanks to developers having found the right option?
>
> This being said, it seems to me that the example that started this
> discussion (building a collection) is among the worst-performing cases for
> the functional-style `reduce`. What are other cases where the inout version
> is a big win? If this is specifically about building collections or
> sequences, could a more specific type signature help?
>
> Arguing both for and against,
> Guillaume Lessard
>
> _______________________________________________
> 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/20170118/86e270b9/attachment.html>