New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Returning Failure from failed P6-level .parse #6450
Comments
From @AlexDanielSee this commit: rakudo/rakudo@9501eda These roast commits: And this justification: This blog post noticing the breakage due to the change: And these thoughts about postponing it to v6.d: 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. |
From @zoffixznetOn Thu, 17 Aug 2017 08:50:48 -0700, alex.jakimenko@gmail.com wrote:
See also timotimo++'s comment that TimToady cleared a revert if there were fallout: https://irclog.perlgeek.de/perl6/2017-08-17#i_15031866
To me, it looks like a clear case for 6.d material. We made a promise to users that we won't make changes that break 6.c-errata changes and IMO the 6.c-errata roast changes due to this feature break that promise. |
The RT System itself - Status changed from 'new' to 'open' |
From @zoffixznetOn Thu, 17 Aug 2017 09:11:21 -0700, cpan@zoffix.com wrote:
Though, since it's a method, we get the whole "can't easily change behaviour of a method between languages" problem... |
From @lizmat
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 :-) |
From @lizmat
Hear hear! |
From @AlexDanielThe change was moved to v6.d in this commit: rakudo/rakudo@d2278b4 On 2017-08-17 08:50:48, alex.jakimenko@gmail.com wrote:
|
From @AlexDanielI had to revert one of the nqp commits related to .parse: Raku/nqp@d4d77b6 Here's a ticket for the module that was affected by the change: css-raku/CSS-Module-raku#10 Most certainly we want this change back ASAP, but it had to be reverted for the release. ♥ On 2017-08-19 05:36:36, alex.jakimenko@gmail.com wrote:
|
From @AlexDanielIt was removed completely for 2017.08 release. Rakudo commit: rakudo/rakudo@465d91a
|
From @dwarringOn Mon, 21 Aug 2017 07:38:56 -0700, alex.jakimenko@gmail.com wrote:
I've had a chance to golf this (somewhat) from CSS::Module. The following fails to parse if I revert Raku/nqp@d4d77b6 grammar Tst { |
1 similar comment
From @dwarringOn Mon, 21 Aug 2017 07:38:56 -0700, alex.jakimenko@gmail.com wrote:
I've had a chance to golf this (somewhat) from CSS::Module. The following fails to parse if I revert Raku/nqp@d4d77b6 grammar Tst { |
Migrated from rt.perl.org#131919 (status was 'open')
Searchable as RT131919$
The text was updated successfully, but these errors were encountered: