> On 18 janv. 2017, at 10:21, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Jan 18, 2017, at 2:11 AM, Chris Eidhof via swift-evolution >> <swift-evolution@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. 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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
