Re: RFC on SlidingSplitter Range

2014-10-03 Thread Nordlöw
On Friday, 3 October 2014 at 21:34:33 UTC, Nordlöw wrote: Why? I cracked it :) See: https://github.com/nordlow/justd/blob/master/range_ex.d#L36 Thanks for all your help! Now I know a lot more about ranges. Do you think anybody is interested in including this in Phobos?

Re: RFC on SlidingSplitter Range

2014-10-03 Thread Nordlöw
On Friday, 3 October 2014 at 21:17:54 UTC, monarch_dodra wrote: Sounds about right, but I didn't really look. std.utf.stride solved all but one thing...namely that https://github.com/nordlow/justd/blob/master/range_ex.d#L131 prints all but last Tuple!(string, string)("", "Nordlöw") Tuple!(st

Re: RFC on SlidingSplitter Range

2014-10-03 Thread monarch_dodra via Digitalmars-d-learn
On Friday, 3 October 2014 at 20:15:33 UTC, Nordlöw wrote: Note that I had to tweak empty() a bit. I don't know if I got right. Could you check? Sounds about right, but I didn't really look. Further I can't get string support to work: writefln("%(%s\n%)", slidingSplitter("Nordlöw")); err

Re: RFC on SlidingSplitter Range

2014-10-03 Thread monarch_dodra via Digitalmars-d-learn
On Friday, 3 October 2014 at 20:28:24 UTC, Nordlöw wrote: On Friday, 3 October 2014 at 20:15:33 UTC, Nordlöw wrote: Could you please take a look again at I made another update at https://github.com/nordlow/justd/blob/master/range_ex.d#L15 I had forgotten to move front and popFront out of sta

Re: RFC on SlidingSplitter Range

2014-10-03 Thread Phil via Digitalmars-d-learn
Is prefix ++ preferred in D because of some specific reason? I recall it, for some containers/iterators, gives smaller/faster codegen in C++? I assume the reason is the same as in C++. As users can provide their own implementations of pre and postfix incrementing, the compiler can't assum

Re: RFC on SlidingSplitter Range

2014-10-03 Thread Nordlöw
On Friday, 3 October 2014 at 20:15:33 UTC, Nordlöw wrote: Could you please take a look again at I made another update at https://github.com/nordlow/justd/blob/master/range_ex.d#L15 I had forgotten to move front and popFront out of static if hasSlicing!R Now auto name = slidingSplitter

Re: RFC on SlidingSplitter Range

2014-10-03 Thread Nordlöw
On Friday, 3 October 2014 at 17:46:18 UTC, monarch_dodra wrote: writefln("%(%s\n%)", slidingSplitter("Nordlöw")); That's a really cool syntax, btw. I got to remember that.

Re: RFC on SlidingSplitter Range

2014-10-03 Thread Nordlöw
On Friday, 3 October 2014 at 17:46:18 UTC, monarch_dodra wrote: I threw this together. I left out checks for infinity in favor of brevity: Could you please take a look again at https://github.com/nordlow/justd/blob/master/range_ex.d#L15 I added all the stuff we talked about. Note that I had

Re: RFC on SlidingSplitter Range

2014-10-03 Thread Nordlöw
On Friday, 3 October 2014 at 19:57:31 UTC, monarch_dodra wrote: Be it C, C++ or D, "pre increment is maybe faster, and is never slower". So as a rule of thumb, unless you should *specifically* require post increment, pre-increment is to be prefered, though in 95% of the cases, it results in t

Re: RFC on SlidingSplitter Range

2014-10-03 Thread monarch_dodra via Digitalmars-d-learn
On Friday, 3 October 2014 at 19:46:10 UTC, Nordlöw wrote: Is prefix ++ preferred in D because of some specific reason? I recall it, for some containers/iterators, gives smaller/faster codegen in C++? Be it C, C++ or D, "pre increment is maybe faster, and is never slower". So as a rule of th

Re: RFC on SlidingSplitter Range

2014-10-03 Thread Nordlöw
On Friday, 3 October 2014 at 19:31:30 UTC, monarch_dodra wrote: The idea is to try to keep as much code in common as possible. You can keep your version, provided you write this for popFront: void popFront() { if (_index < _data.length) { static if (isNarrowS

Re: RFC on SlidingSplitter Range

2014-10-03 Thread monarch_dodra via Digitalmars-d-learn
On Friday, 3 October 2014 at 19:12:54 UTC, Nordlöw wrote: On Friday, 3 October 2014 at 17:46:18 UTC, monarch_dodra wrote: If your implementation use two ranges that you slice "on the fly", then you can trivially support strings, thanks to popFront. Very clever. That's what I wanted. I threw

Re: RFC on SlidingSplitter Range

2014-10-03 Thread Nordlöw
On Friday, 3 October 2014 at 17:46:18 UTC, monarch_dodra wrote: My mistake. It's fixed now. Well, yes and no. You are still providing a moveFront that does not conform to what the range interface expects. EG: auto app = appender(); auto myRange = slidingSplitter([1, 2, 3]); for ( ; !myRange.

Re: RFC on SlidingSplitter Range

2014-10-03 Thread monarch_dodra via Digitalmars-d-learn
On Friday, 3 October 2014 at 17:06:41 UTC, Nordlöw wrote: On Friday, 3 October 2014 at 16:32:24 UTC, monarch_dodra wrote: If anything, I'd have expected you to provide something returns the popped element. What you do pops an element, and then returns the *next* one. What good is that? My mis

Re: RFC on SlidingSplitter Range

2014-10-03 Thread Nordlöw
On Friday, 3 October 2014 at 16:32:24 UTC, monarch_dodra wrote: If anything, I'd have expected you to provide something returns the popped element. What you do pops an element, and then returns the *next* one. What good is that? My mistake. It's fixed now. Also, what you want to check is "has

Re: RFC on SlidingSplitter Range

2014-10-03 Thread monarch_dodra via Digitalmars-d-learn
On Friday, 3 October 2014 at 15:22:06 UTC, Nordlöw wrote: Destroy, please! As a quick comment, your definition of "moveFront" is not what phobos understands with "moveFront": https://github.com/D-Programming-Language/phobos/blob/7914fa31cb3b53f4e50421399f2b99d2012e8031/std/range.d#L8267 Name

Re: RFC on SlidingSplitter Range

2014-10-03 Thread John Colvin via Digitalmars-d-learn
On Friday, 3 October 2014 at 15:22:06 UTC, Nordlöw wrote: As a follow up to http://forum.dlang.org/thread/dndicafxfubzmndeh...@forum.dlang.org I've begun implementing a new range, I currently call, SlidingSplitter at https://github.com/nordlow/justd/blob/master/range_ex.d#L12 I would now ve