[Issue 8155] Deprecate std.range.lockstep
https://issues.dlang.org/show_bug.cgi?id=8155 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |RESOLVED CC||and...@erdani.com Resolution|--- |WONTFIX --
[Issue 8155] Deprecate std.range.lockstep
https://issues.dlang.org/show_bug.cgi?id=8155 Jack Stouffer changed: What|Removed |Added CC||j...@jackstouffer.com Depends on||10541 --
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #17 from Joseph Rushton Wakeling 2013-07-04 03:10:53 PDT --- (In reply to comment #16) > If not already present I suggest you to open an enhancement request that asks > for your improvement of zip, and then we'll make this issue dependant to the > other one. They are two separate issues. Done: Issue #10541. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #16 from bearophile_h...@eml.cc 2013-06-29 03:16:46 PDT --- (In reply to comment #14) > I think deprecating lockstep in favour of zip is a no-no unless > one can do a systematic replace, 's/lockstep/zip/' and have the new code Just > Work. If not already present I suggest you to open an enhancement request that asks for your improvement of zip, and then we'll make this issue dependant to the other one. They are two separate issues. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #15 from Joseph Rushton Wakeling 2013-06-29 02:50:34 PDT --- (In reply to comment #14) > Glancing through the code, it looks like an issue of design difference > rather than a bug per se. The docs note that std.range.zip "offers mutation and swapping if all ranges offer it". Hence the problem if one of the ranges is e.g. iota(), rather than iota().array(). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #14 from Joseph Rushton Wakeling 2013-06-29 02:48:35 PDT --- (In reply to comment #13) > I see, for that I sometimes use a pattern like this: Very cool! :-) Nevertheless, I think deprecating lockstep in favour of zip is a no-no unless one can do a systematic replace, 's/lockstep/zip/' and have the new code Just Work. Glancing through the code, it looks like an issue of design difference rather than a bug per se. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155
--- Comment #13 from bearophile_h...@eml.cc 2013-06-28 17:18:28 PDT ---
(In reply to comment #12)
> In my real application, the value of x was determined by some rather complex
> calculations for which i was a parameter, so copy doesn't work either ... :-)
I see, for that I sometimes use a pattern like this:
import std.stdio, std.array, std.algorithm;
int calculations(TP)(TP ix) pure nothrow { return ix[1] ^^ 2 + ix[0]; }
void main() {
auto arr = [10, 20, 30];
arr.enumerate.map!calculations.copy(arr);
arr.writeln;
}
If calculations() is pure and slow, then perhaps it's worth using a amap from
std.parallelism (but I don't know how well it interacts with the copy).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #12 from Joseph Rushton Wakeling 2013-06-28 15:51:51 PDT --- (In reply to comment #11) > Such cases are better solved using the copy() algorithm. I accept the point, but I still think that the code given shouldn't fail with zip. In my real application, the value of x was determined by some rather complex calculations for which i was a parameter, so copy doesn't work either ... :-) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #11 from bearophile_h...@eml.cc 2013-06-28 13:57:42 PDT --- (In reply to comment #10) > Thanks for the useful hint :-) In fact in the general case where I discovered > this issue, the use case was more, > > foreach(i, ref x; lockstep(arrIndex, arr1)) > x = i; > > ... where arrIndex does not _necessarily_ contain the sequence 0, 1, 2, 3, 4, > ... Such cases are better solved using the copy() algorithm. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #10 from Joseph Rushton Wakeling 2013-06-28 13:21:31 PDT --- (In reply to comment #9) > Let me add a note. For your specific use case it's better to use enumerate(), > from Issue 5550 : > > auto arr1 = new double[10]; > foreach (i, ref x; arr1.enumerate) > x = i; > arr1.writeln; Thanks for the useful hint :-) In fact in the general case where I discovered this issue, the use case was more, foreach(i, ref x; lockstep(arrIndex, arr1)) x = i; ... where arrIndex does not _necessarily_ contain the sequence 0, 1, 2, 3, 4, ... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155
--- Comment #9 from bearophile_h...@eml.cc 2013-06-28 09:46:37 PDT ---
(In reply to comment #8)
> auto arr1 = new double[10];
> foreach(i, ref x; zip(iota(10), arr1))
> {
> x = i;
> }
> writeln(arr1);
>
> auto arr2 = new double[10];
> foreach(i, ref x; lockstep(iota(10), arr2))
> {
> x = i;
> }
> writeln(arr2);
Let me add a note. For your specific use case it's better to use enumerate(),
from Issue 5550 :
auto arr1 = new double[10];
foreach (i, ref x; arr1.enumerate)
x = i;
arr1.writeln;
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155
Joseph Rushton Wakeling changed:
What|Removed |Added
CC||joseph.wakel...@webdrake.ne
||t
--- Comment #8 from Joseph Rushton Wakeling
2013-06-28 06:19:31 PDT ---
(In reply to comment #0)
> I suggest to deprecate std.range.lockstep because with the recent improvements
> in tuple unpacking, std.range.zip is able to replace its the main purpose
There are currently some things that work with lockstep that don't with zip.
Consider:
auto arr1 = new double[10];
foreach(i, ref x; zip(iota(10), arr1))
{
x = i;
}
writeln(arr1);
auto arr2 = new double[10];
foreach(i, ref x; lockstep(iota(10), arr2))
{
x = i;
}
writeln(arr2);
The first array will output all nan's, the second will have values set
correctly. I imagine this is a bug, but it needs to be fixed before zip is a
viable lockstep replacement.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #7 from bearophile_h...@eml.cc 2012-06-05 16:36:14 PDT --- (In reply to comment #6) > You might introduce a new template tomorrow, and then remove it a month later, > so why should I even bother coding against such a library? Is Phobos someone's > playground or a standard library? Take a look at the Phobos2 changelog for DMD 2.060. There are functions and four whole modules removed from Phobos2: https://github.com/D-Programming-Language/phobos/blob/08a62cdaaa37fd7168bb6bf0d63f00ead1eeb4d0/changelog.dd I think two more modules will be removed in August this year. Phobos2 is young still, it contains many mistakes, so it's better to fix it. In some years the rate of deprecation will probably decrease. In D there is the deprecated keyword, and other things that help the deprecation process. They are meant to be used. I am not asking to remove lockstep() today, I suggest to follow a normal sane path of announcing a deprecation, deprecate it some months later (but keep it for a year or so) and then remove it. Removing redundant/bad/broken functions/things from Phobos is useful, because it reduces the efforts to learn to use D+Phobos. A bit of growing pain is acceptable, especially in the first years, if they spare a bigger amount of pain/work/confusion later. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #6 from Andrej Mitrovic 2012-06-05 15:18:38 PDT --- (In reply to comment #4) > (In reply to comment #3) > > Yes let's break code > > You can't assume Phobos will not change. You might introduce a new template tomorrow, and then remove it a month later, so why should I even bother coding against such a library? Is Phobos someone's playground or a standard library? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #5 from bearophile_h...@eml.cc 2012-06-05 15:04:06 PDT --- (In reply to comment #3) > Yes let's break code and make new code more verbose, great idea. Your answers have made those arguments of mine stronger, so thank you for your useful comments. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #4 from bearophile_h...@eml.cc 2012-06-05 15:01:26 PDT --- (In reply to comment #3) > Yes let's break code You can't assume Phobos will not change. Some parts of Phobos were designed very quickly, and not at their best. We need deprecation patterns, new better things to be introduced and older less-well designed things deprecated and removed. In hindsight the decision to add lockstep() was a mistake, it was based on a limit of D language that Hara has quickly removed, allowing zip() to cover most usages of lockstep(). Now lockstep() is redundant because you are able to avoid it just calling another function. As you know Walter prefers to not add shallow functions to Phobos. If you assume lockstep() is not present in Phobos and you want to add it, people will say you that zip().enumerate() (or other similarly simple solutions) is able to replace it, so it's too much shallow to add it. In my opinion to add a shallow function to Phobos it must replace a very often used pattern, as filter().array(). While I think zip().enumerate() is not one of such very common patterns. > and make new code more verbose, It's a little more verbose, but the need of a index is not common when you zip iterables, so the _total_ increase of code is very small. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #3 from Andrej Mitrovic 2012-06-05 14:15:51 PDT --- Yes let's break code and make new code more verbose, great idea. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 --- Comment #2 from bearophile_h...@eml.cc 2012-06-05 13:45:11 PDT --- (In reply to comment #1) > Sorry, but I *do* use the index variable: I didn't said that index variable is never useful and never used. I have said its need is rare, in my experience of using Python and in my experience of looking at Haskell code. On the other hand I have shown and offered 3 different ways to solve the problem without lockstep. lockstep is redundant, and its usage doesn't shorten a significant amount of code: there are redundant operations that are way more commonly useful than lockstep, like amap/afilter. > https://github.com/AndrejMitrovic/DWinProgramming/blob/master/Samples/Chap06/KeyView1/KeyView1.d#L198 > https://github.com/AndrejMitrovic/DWinProgramming/blob/master/Samples/Chap09/BtnLook/BtnLook.d#L144 Of the 3 alternative solution, using enumerate, those: foreach (index, button, ref hwndButton; lockstep(buttons, hwndButtons)) foreach (index, myMsg; lockstep(iota(0, min(cLines, cyClient / cyChar - 1)), retro(msgArr))) Become: foreach (index, button, ref hwndButton; enumerate(zip(buttons, hwndButtons))) foreach (index, myMsg; enumerate(zip(iota(min(cLines, cyClient / cyChar - 1)), retro(msgArr Or maybe: foreach (index, button, ref hwndButton; buttons.zip(hwndButtons).enumerate()) foreach (index, myMsg; min(cLines, cyClient / cyChar - 1).iota().zip(msgArr.retro()).enumerate()) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8155] Deprecate std.range.lockstep
http://d.puremagic.com/issues/show_bug.cgi?id=8155 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2012-06-05 10:57:56 PDT --- Sorry, but I *do* use the index variable: https://github.com/AndrejMitrovic/DWinProgramming/blob/master/Samples/Chap06/KeyView1/KeyView1.d#L198 https://github.com/AndrejMitrovic/DWinProgramming/blob/master/Samples/Chap09/BtnLook/BtnLook.d#L144 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
