www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11929] New: Disallow `ref` in front tuple expansion in foreach over range

reply d-bugmail puremagic.com writes:
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


--- Comment #0 from Denis Shelomovskij <verylonglogin.reg gmail.com> 2014-01-15
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
next sibling parent d-bugmail puremagic.com writes:
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


--- Comment #1 from Maxim Fomin <maxim maxim-fomin.ru> 2014-01-15 01:39:33 PST
---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11929



--- Comment #2 from Denis Shelomovskij <verylonglogin.reg gmail.com> 2014-01-15
18:24:11 MSK ---
(In reply to comment #1)
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11929



--- Comment #3 from Maxim Fomin <maxim maxim-fomin.ru> 2014-01-15 07:25:04 PST
---
(In reply to comment #2)
 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
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11929



--- Comment #4 from Denis Shelomovskij <verylonglogin.reg gmail.com> 2014-01-16
11:57:32 MSK ---
(In reply to comment #3)
 (In reply to comment #2)
 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?

Neither. For tuple expansion in `foreach` over range only as written in description.
 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 call expression like in C#, it's another already discussed issue. 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