<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 18, 2017 at 10:33 AM Guillaume Lessard via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On 18 janv. 2017, at 10:21, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
>> On Jan 18, 2017, at 2:11 AM, Chris Eidhof via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> 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.<br class="gmail_msg">
><br class="gmail_msg">
> 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.<br class="gmail_msg">
<br class="gmail_msg">
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.<br class="gmail_msg"></blockquote><div><br></div><div>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.)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
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?<br class="gmail_msg">
<br class="gmail_msg">
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?<br class="gmail_msg">
<br class="gmail_msg">
Arguing both for and against,<br class="gmail_msg">
Guillaume Lessard<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>