> On 17 Aug 2017, at 17:50, Aleks-Daniel Jakimenko-Aleksejev (via RT) > <perl6-bugs-follo...@perl.org> wrote: > > # New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev > # Please include the string: [perl #131919] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=131919 > > > > See this commit: > https://github.com/rakudo/rakudo/commit/9501edae4f73a970e3270e3b0336a7b3045d3329 > > These roast commits: > * > https://github.com/perl6/roast/commit/1fb68c4b7a7c975f26fc81ad79f000958d1b4afd > * > https://github.com/perl6/roast/commit/b53616f8e67f9b19366008b3abf55400a3d6cd2b > > And this justification: > * https://irclog.perlgeek.de/perl6-dev/2017-08-16#i_15021994 > > This blog post noticing the breakage due to the change: > * https://gfldex.wordpress.com/2017/08/17/parsing-nothing/ > > And these thoughts about postponing it to v6.d: > * https://irclog.perlgeek.de/perl6-dev/2017-08-17#i_15032160 > > > I am confident that we will not be able to process this change and all > potential breakage associated with it in ≈3 days before the release, so the > revert is coming. > > Personally, I don't mind rereverting it afterwards for inclusion in 2017.09, > assuming we make sure to fix all modules that were relying on Nils being > returned. However, I do see the point for postponing it till v6.d. > > > So should we feel adventurous and push this change as early as we can (in > 2017.09, aftear at least one month)? Or is it better to be safe and wait for > v6.d? Please discuss.
My feeling is to put this towards 6.d. And possibly have that coincide with 2017.09. The reason? This feature, like other features such as “is default” working on attributes, can *still* not be used on any module in the ecosystem, because one cannot be sure it won’t get run by a version of 6.c that does not have that feature already: case in point, not gaining about 5% in performance in Text::CSV because we cannot use “has $!foo is default()”. I think we’ve collected so many incompatible features by now that we need a 6.d earlier rather than later. At least from the API point of view. AKA, make things work for 6.d, then start optimizing again :-)
