{"action":"created","issue":{"url":"https://api.github.com/repos/rakudo/rakudo/issues/1020","repository_url":"https://api.github.com/repos/rakudo/rakudo","labels_url":"https://api.github.com/repos/rakudo/rakudo/issues/1020/labels{/name}","comments_url":"https://api.github.com/repos/rakudo/rakudo/issues/1020/comments","events_url":"https://api.github.com/repos/rakudo/rakudo/issues/1020/events","html_url":"https://github.com/rakudo/rakudo/pull/1020","id":208497483,"number":1020,"title":"Revert \"forbid to put variable in initializer of its declaration\"","user":{"login":"AlexDaniel","id":5507503,"avatar_url":"https://avatars0.githubusercontent.com/u/5507503?v=3","gravatar_id":"","url":"https://api.github.com/users/AlexDaniel","html_url":"https://github.com/AlexDaniel","followers_url":"https://api.github.com/users/AlexDaniel/followers","following_url":"https://api.github.com/users/AlexDaniel/following{/other_user}","gists_url":"https://api.github.com/users/AlexDaniel/gists{/gist_id}","starred_url":"https://api.github.com/users/AlexDaniel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/AlexDaniel/subscriptions","organizations_url":"https://api.github.com/users/AlexDaniel/orgs","repos_url":"https://api.github.com/users/AlexDaniel/repos","events_url":"https://api.github.com/users/AlexDaniel/events{/privacy}","received_events_url":"https://api.github.com/users/AlexDaniel/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2017-02-17T16:53:24Z","updated_at":"2017-03-18T18:59:23Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/rakudo/rakudo/pulls/1020","html_url":"https://github.com/rakudo/rakudo/pull/1020","diff_url":"https://github.com/rakudo/rakudo/pull/1020.diff","patch_url":"https://github.com/rakudo/rakudo/pull/1020.patch"},"body":"Aka “Allow self-referential arrays in declarations”\r\n\r\nThis reverts commit 3754356d8e4401c2e567f20462adb2ecd97dc7d5.\r\n\r\nTL;DR Reverted commit does more harm than good, and with recent\r\nchanges is no longer needed as much. There are ways you can shoot\r\nyourself in the foot, yes, and we should find a way to print awesome\r\nerror messages in these cases.\r\n\r\nThe change in the reverted commit achieves very little. In theory, it\r\nprevented obvious ways to create a VMNull (and nulls used to blow\r\nup). An example of the issue that was masqueraded:\r\n\r\n    my $a := $a; say $a  # segfaulted previously\r\n\r\nAt the same time, it didn't prevent any other ways of achieving the\r\nsame thing. For example:\r\n\r\n    my $a := $::a; say $a  # segfault, even after the fix!\r\n\r\nHowever, the change prevented legitimate creation of self-referential\r\narrays:\r\n\r\n    my @a = 42, @a    # ← complains needlessly\r\n\r\nAnd forced to use workarounds to achieve it:\r\n\r\n    my @a = 42, @::a  # ← does not complain and works perfectly.\r\n                      # Congratulations, you've tricked the detection!\r\n\r\nA proper way to fix the issue would be to prevent the segfault.\r\nIt was done in ae2ae92330e5b861b47500de0d8b0855297757a3 (actual\r\nMoarVM/nqp commit unknown).\r\n\r\nThere's a good point that the user may have wrong assumptions on how\r\nself-referential stuff should work with binding, and we should have a\r\ncompile-time error for this case. DIHWIDT, but would be nice if\r\nsomebody came up with a proper way to detect this.\r\n\r\nIn other words: it does not segfault anymore, so this “fix” is not\r\nneeded. And even though the behavior is LTA when you get a VMNull\r\nanywhere, it does not warrant the prevention of a legitimate use of\r\nself-referential arrays (or hashes, pairs, lists, etc.).\r\n\r\nThe revert had conflicts because of these commits:\r\n* 1458f0ea3ea2943252c4436fd66a22861845f8ad\r\n* ae651044245eabcfe172813ad3f5bab377025f51\r\n\r\nI had to tweak it a bit to resolve the issues, should be OK.\r\n\r\nObviously, doesn't pass spectest because of misguided tests for the\r\nreverted commit. This has to be corrected in errata."},"comment":{"url":"https://api.github.com/repos/rakudo/rakudo/issues/comments/287567104","html_url":"https://github.com/rakudo/rakudo/pull/1020#issuecomment-287567104","issue_url":"https://api.github.com/repos/rakudo/rakudo/issues/1020","id":287567104,"user":{"login":"AlexDaniel","id":5507503,"avatar_url":"https://avatars0.githubusercontent.com/u/5507503?v=3","gravatar_id":"","url":"https://api.github.com/users/AlexDaniel","html_url":"https://github.com/AlexDaniel","followers_url":"https://api.github.com/users/AlexDaniel/followers","following_url":"https://api.github.com/users/AlexDaniel/following{/other_user}","gists_url":"https://api.github.com/users/AlexDaniel/gists{/gist_id}","starred_url":"https://api.github.com/users/AlexDaniel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/AlexDaniel/subscriptions","organizations_url":"https://api.github.com/users/AlexDaniel/orgs","repos_url":"https://api.github.com/users/AlexDaniel/repos","events_url":"https://api.github.com/users/AlexDaniel/events{/privacy}","received_events_url":"https://api.github.com/users/AlexDaniel/received_events","type":"User","site_admin":false},"created_at":"2017-03-18T18:59:23Z","updated_at":"2017-03-18T18:59:23Z","body":"1. Yes, similarly to how a broken clock is right once a day, there is indeed **one** case when the error is what one can maybe call right (when using binding), and in the rest of the cases the error is wrong.\r\n2. What tests are we talking about exactly? There is one test that tests ``my %h is default(%h<foo>)``, and the error has nothing to do with what actually happens. That test has to be removed anyway. And then there is another test with ``my $z = $z``, which, interestingly, has never been a problem. The last test is for ``my @foo := 1..3, (@foo Z+ 100)``, which, again, is a perfectly valid code except that one should use normal assignment instead of binding. In theory, there could be an error which would suggest normal assignment, that would be pretty nice indeed. Anyway, I've already explained this in #236.\r\n\r\nWe can wait for 6.d, I guess (but then it is unclear what should be done with wrong behavior right now). Or we can try to somehow keep the error in this one “useful” case mentioned above… Meh."}}
{"actor":{"display_login":"AlexDaniel"}}