“Will leave this ticket open a little longer for further comments/discussion, but my intention is to reject it.”
Nope, that's not exactly a good sounding plan. We'll run toaster and fix all modules that require fixing (or create appropriate issues if fixing something turns out to be too hard). This is exactly what I did for Grammar.parse change before the previous release (even though we reverted it anyway). And this is what I'm planning to do for this change also. You are 100% right about the change, but flipping the ecosystem upside down is not exactly a good strategy even if you're right. On 2017-09-05 09:11:19, allber...@gmail.com wrote: > On Tue, Sep 5, 2017 at 5:40 AM, jn...@jnthn.net via RT < > perl6-bugs-follo...@perl.org> wrote: > > > Failing to close output handles has been clearly documented (and yes, > > documented well before the recent buffering change) as something that can > > cause data loss. Default output buffering just makes it quite a lot more > > likely to show up. > > > > While there will be some ecosystem fallout like this, unfortunately I > > don't think it's avoidable. If we whip out the patch that turns output > > buffering on by default for non-TTYs for this release, then when will we > > include it? The longer we leave it, the more painful it will be, because > > more code will be written that is careless with handles. > > > > I don't think "leave it off by default" is a good option either, otherwise > > we get to spend the next decade hearing "Perl 6 I/O is slow" because it'd > > be one of the only languages that doesn't buffer its output without an > > explicit flag being passed to enable that (which nearly nobody doing quick > > benchmarks will know to use). > > > > Are we missing something to flush/close handles at exit? Leaving it to a GC > that may not finalize before exit is not really an option. >
