https://d.puremagic.com/issues/show_bug.cgi?id=11929
--- Comment #4 from Denis Shelomovskij <[email protected]> 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: -------
