digitalmars.D.bugs - [Issue 11929] New: Disallow `ref` in front tuple expansion in foreach over range
- d-bugmail puremagic.com (34/34) Jan 15 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11929
- d-bugmail puremagic.com (12/12) Jan 15 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11929
- d-bugmail puremagic.com (13/16) Jan 15 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11929
- d-bugmail puremagic.com (17/23) Jan 15 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11929
- d-bugmail puremagic.com (16/39) Jan 15 2014 https://d.puremagic.com/issues/show_bug.cgi?id=11929
https://d.puremagic.com/issues/show_bug.cgi?id=11929 Summary: Disallow `ref` in front tuple expansion in foreach over range Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: accepts-invalid Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: verylonglogin.reg gmail.com 12:46:34 MSK --- As currently `ref` is allowed in front tuple expansion such dangerous code is accepted and fails only in runtime: --- import std.range; void main() { int[] arr = new int[1]; foreach(ref a, b; zip(arr, new int[1])) ++a; assert(arr[0] == 1); } --- IMO such code should reject to compile as I see no general use for access to tuple element by `ref`. Broken after such change code most likely is invalid. Also front tuple expansion in foreach over range isn't documented. See Issue 7361. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 15 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11929 Maxim Fomin <maxim maxim-fomin.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maxim maxim-fomin.ru --- Are you arguing against ref parameters in for/foreach loop in general? I see no reason for it because the root of the problem is in putting ref (and there is no reason for it), so it is PEBKAC. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 15 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11929 18:24:11 MSK ---Are you arguing against ref parameters in for/foreach loop in general? I see no reason for it because the root of the problem is in putting ref (and there is no reason for it), so it is PEBKAC.Thanks for the sarcasm. Probably I should add more description: Ranges of tuples generally contains generated somehow based on source ranges tuples (e.g. `zip` and `group`) so access to tuple elements by `ref` is a nonsense. As D type system doesn't provide head const I see no way to mark tuple elements non-`ref`able so I suggest to disallow such access in general as I'm not aware of cases where such functionality is needed. And even if there are such cases IHO its support doesn't worth potential confusion. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 15 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11929 ---Ranges of tuples generally contains generated somehow based on source ranges tuples (e.g. `zip` and `group`) so access to tuple elements by `ref` is a nonsense. As D type system doesn't provide head const I see no way to mark tuple elements non-`ref`able so I suggest to disallow such access in general as I'm not aware of cases where such functionality is needed. And even if there are such cases IHO its support doesn't worth potential confusion.I still don't understand the scope of proposed limitation. Foreach over ranges or foreach in general? By the way, what you are asking can be reformulated as: void foo(ref int i) { i = 0; } void main() { int i = 1; i.foo(); //oops, i = 0, let's ban ref attribute in function parameters } Why one should put 'ref' (supposedly unconsciously?) and then complain about it? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 15 2014
https://d.puremagic.com/issues/show_bug.cgi?id=11929 11:57:32 MSK ---Neither. For tuple expansion in `foreach` over range only as written in description.Ranges of tuples generally contains generated somehow based on source ranges tuples (e.g. `zip` and `group`) so access to tuple elements by `ref` is a nonsense. As D type system doesn't provide head const I see no way to mark tuple elements non-`ref`able so I suggest to disallow such access in general as I'm not aware of cases where such functionality is needed. And even if there are such cases IHO its support doesn't worth potential confusion.I still don't understand the scope of proposed limitation. Foreach over ranges or foreach in general?By the way, what you are asking can be reformulated as: void foo(ref int i) { i = 0; } void main() { int i = 1; i.foo(); //oops, i = 0, let's ban ref attribute in function parameters } Why one should put 'ref' (supposedly unconsciously?) and then complain about it?Your example is about a requirement to explicitly specify `ref` in function calls has nothing to do with this bug report. In this issue it's proposed to disable `ref` in front tuple expansion case because in general created tuple is a temporary. Also I noted the issue exists in `foreach` over ranges in general, not just in tuple expansion case so I filed Issue 11934 for range problem and Issue 11935 that is a better solution for the problem described in this one. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 15 2014