On 07/05/2012 01:26 AM, Jonathan M Davis wrote:
I wonder how the results look on gdc when using the improved popFront, given
how surprising they were with consumeFront.
Improved popFront, gdc as before (-frelease -finline-functions -fweb -O3):
ascii 22.69%: old [2 secs, 449 ms, 248 μs, and 7
On 04-Jul-12 19:17, Andrei Alexandrescu wrote:
On 7/4/12 8:33 AM, deadalnix wrote:
Le 04/07/2012 13:04, Roman D. Boiko a écrit :
On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
I do agree with that. However, the current proposal have the same
drawback but on the code that use the
On Wednesday, 4 July 2012 at 22:02:28 UTC, deadalnix wrote:
Le 04/07/2012 21:45, Jonathan M Davis a écrit :
On Wednesday, July 04, 2012 12:19:15 Jonathan M Davis wrote:
But at present, I'm seeing a performance improvement of
approximately 70 -
80% in iterating over strings with consumeFront
If you really don't need the value, you could devise a justPop method
that does not return (by the way, overloading by return type would be an
amazing feature here). The idea is not we should return a value
everytime we pop, but we should pop when we return a value.
--
Christophe
On Thursday, 5 July 2012 at 08:34:29 UTC, Roman D. Boiko wrote:
I make no conclusions, because have not run any benchmarks to
estimate how complex the code should be to take those 30 ms.
Such benchmarks would be valuable for discussion.
That has been written before I saw all benchmarks, so my
On Wednesday, 4 July 2012 at 22:08:18 UTC, Jonathan M Davis wrote:
C++'s iterators definitely do _not_ return an element when you
increment them.
- Jonathan M Davis
Just a thought, but C++'s input iterator very often do increment
when being _dereferenced_, and then they make the _increment_
monarch_dodra , dans le message (digitalmars.D:171175), a écrit :
For those few algorithms that work on bidirRange, we'd need a
garantee that they don't ever front/back the same item twice. We
*could* achieve this by defining a bidirectionalInputRange class
of range.
filter does that. If
Le 05/07/2012 01:06, Jonathan M Davis a écrit :
Another option would be to create a wrapper range for strings to be used when
they already have to be wrapped in another range. Functions which want to make
string processing more efficient can already specialize on strings (and often
do), so they
On 7/5/12 1:26 AM, Jonathan M Davis wrote:
In any case, I guess that this shows that what we can get with popFront is so
close to what consumeFront or StringCache would do that we might as well not
bother with them, which is a _big_ surpise to me. It does pay to benchmark
code though.
Good
On 07/05/2012 02:35 AM, Ed McCardell wrote:
When gdc finishes building on my 64-bit box I can run timings on that,
There also seems to be a speed improvement for consumeFront on 64-bit
gdc, with both standard and Andrei's improved popFront:
standard popfront:
ascii 35.95%: old [3 secs,
(grain of salt, I'm new to D.)
I'd vote for consumeFront being always available, because it's
distinctly more convenient to call one function instead of two,
especially when you expect that making a copy of front is cheap
(e.g. a collection of pointers, numbers or slices). Ranges where
On Thursday, July 05, 2012 23:59:47 David Piepgrass wrote:
(grain of salt, I'm new to D.)
I'd vote for consumeFront being always available, because it's
distinctly more convenient to call one function instead of two,
especially when you expect that making a copy of front is cheap
(e.g. a
On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis wrote:
Okay, given the fact that takeFront wouldn't work with ranges
like
std.stdio.ByLine, the code as proposed won't work. So, here's
an adjusted
proposal:
On Wednesday, 4 July 2012 at 07:40:55 UTC, monarch_dodra wrote:
I'll propose spendFront, which is pretty much the same thing,
but is less loaded. I'm not entirely sure if it carries the
meaning as well? I think it is a worth discussion.
I'm not a native speaker, but I feel that spend would be
On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis wrote:
If no one has any major objections to this scheme or can
provide a better proposal, I'll create a pull request from what
I have.
No objections.
Still would be nice to get your (or community) feedback on my
previous proposals
On Wednesday, 4 July 2012 at 07:53:32 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 07:40:55 UTC, monarch_dodra wrote:
I'll propose spendFront, which is pretty much the same
thing, but is less loaded. I'm not entirely sure if it carries
the meaning as well? I think it is a worth
On Wednesday, July 04, 2012 09:58:09 Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 07:53:32 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 07:40:55 UTC, monarch_dodra wrote:
I'll propose spendFront, which is pretty much the same
thing, but is less loaded. I'm not entirely sure
What's wrong with moveFront()?
On Wednesday, 4 July 2012 at 08:12:46 UTC, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 09:58:09 Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 07:53:32 UTC, Roman D. Boiko
wrote:
On Wednesday, 4 July 2012 at 07:40:55 UTC, monarch_dodra
wrote:
I'll propose spendFront, which is
On Wednesday, July 04, 2012 09:55:57 Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis wrote:
If no one has any major objections to this scheme or can
provide a better proposal, I'll create a pull request from what
I have.
No objections.
Still would be
On Wednesday, 4 July 2012 at 07:58:11 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 07:53:32 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 07:40:55 UTC, monarch_dodra wrote:
I'll propose spendFront, which is pretty much the same
thing, but is less loaded. I'm not entirely
On Wednesday, 4 July 2012 at 08:13:10 UTC, Mehrdad wrote:
What's wrong with moveFront()?
+ it's used in std.container, too.
- in std.container the length of the container is invariant
under moveFront,
with the proposal here this would not be the case. So it's
similar but inconsistent.
On Wednesday, 4 July 2012 at 08:13:10 UTC, Mehrdad wrote:
What's wrong with moveFront()?
It has different semantics. For example, it is only supported for
ranges which have movable elements. After moveFront, the element
which was placed in the front position is replaced by E.init (E
is
On Wednesday, 4 July 2012 at 08:14:54 UTC, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 09:55:57 Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis
wrote:
If no one has any major objections to this scheme or can
provide a better proposal, I'll create a
On Wednesday, 4 July 2012 at 08:16:32 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 08:13:10 UTC, Mehrdad wrote:
What's wrong with moveFront()?
It has different semantics. For example, it is only supported
for ranges which have movable elements. After moveFront, the
element which
On Wednesday, 4 July 2012 at 08:18:35 UTC, Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:16:32 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 08:13:10 UTC, Mehrdad wrote:
What's wrong with moveFront()?
It has different semantics. For example, it is only supported
for ranges which
On Wednesday, 4 July 2012 at 08:13:20 UTC, Tobias Pankrath wrote:
The name must imply that the range will be changed, i.e. after
the call the value is not part of the range anymore.
consume does this, fetch does this, too. read does not
Where have you last ever seen a read() method whose
On Wednesday, 4 July 2012 at 08:25:19 UTC, Mehrdad wrote:
Where have you last ever seen a read() method whose default
behavior was NOT to modify the
collection/range/iterator/stream/whatever?
+1
On Wednesday, 4 July 2012 at 08:20:59 UTC, Mehrdad wrote:
I propose we just allow (but not require) popFront() to return
ElementType!(R) instead of void?
That way, people who need the performance can check to see the
return type, and use it without front() if needed.
That would be almost
On Wednesday, 4 July 2012 at 08:25:59 UTC, Roman D. Boiko wrote:
That would be almost perfect. But has drawbacks:
* if element is big and may be not needed in all calls to
popFront (when the user wants to ignore elements), there would
be some overhead;
Could you give an example of such a
On Wednesday, July 04, 2012 10:16:05 Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:14:54 UTC, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 09:55:57 Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis
wrote:
If no one has any major objections to
On Wednesday, 4 July 2012 at 08:14:54 UTC, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 09:55:57 Roman D. Boiko wrote:
Still would be nice to get your (or community) feedback on my
previous proposals to localize custom logic inside ranges which
invalidate value returned from front.
It
On Wednesday, July 04, 2012 10:20:58 Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:18:35 UTC, Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:16:32 UTC, Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 08:13:10 UTC, Mehrdad wrote:
What's wrong with moveFront()?
It has different
On Wednesday, 4 July 2012 at 08:31:05 UTC, Jonathan M Davis wrote:
He was suggesting that a range like ByLine define consumeFront
and then play games to make it work. So, instead of doing the
equivalent of
auto retval = range.front;
range.popFront();
return retval;
only more efficiently, it
On Wednesday, 4 July 2012 at 08:25:19 UTC, Mehrdad wrote:
Where have you last ever seen a read() method whose default
behavior was NOT to modify the
collection/range/iterator/stream/whatever?
That's a good question. When writing it, I was thinking about
real world analogies like reading a
On Wednesday, 4 July 2012 at 08:35:30 UTC, Dmitry Olshansky wrote:
On 04-Jul-12 12:29, Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:25:59 UTC, Roman D. Boiko
wrote:
That would be almost perfect. But has drawbacks:
* if element is big and may be not needed in all calls to
popFront
(when the
On 04-Jul-12 12:29, Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:25:59 UTC, Roman D. Boiko wrote:
That would be almost perfect. But has drawbacks:
* if element is big and may be not needed in all calls to popFront
(when the user wants to ignore elements), there would be some overhead;
On Wednesday, July 04, 2012 10:25:18 Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:13:20 UTC, Tobias Pankrath wrote:
The name must imply that the range will be changed, i.e. after
the call the value is not part of the range anymore.
consume does this, fetch does this, too. read does not
On Wednesday, 4 July 2012 at 08:31:05 UTC, Jonathan M Davis wrote:
But if the default is that there is no consumeFront, then it'll
only be there when the programmer determines that they need it
and defines it. So, the default is safe, but the option of
efficiency is there if the programmer
On Wednesday, July 04, 2012 10:37:41 Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:35:30 UTC, Dmitry Olshansky wrote:
On 04-Jul-12 12:29, Mehrdad wrote:
On Wednesday, 4 July 2012 at 08:25:59 UTC, Roman D. Boiko
wrote:
That would be almost perfect. But has drawbacks:
* if element
On Wednesday, 4 July 2012 at 08:40:46 UTC, Jonathan M Davis wrote:
It depends on the API. All that the word read indicates is that
data was read.
It doesn't indicate anything about what was read from or what
happened to it.
In some cases, read doesn't alter what's read at all. In others
it
On Wednesday, July 04, 2012 10:43:04 Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 08:31:05 UTC, Jonathan M Davis wrote:
But if the default is that there is no consumeFront, then it'll
only be there when the programmer determines that they need it
and defines it. So, the default is
On 07/04/2012 04:50 AM, Jonathan M Davis wrote:
But reducing code was never my concern (nor Dmitry's in considering proposing
essentially the same thing). It's efficiency that's the problem - particularly
with strings. IIRC, with the tests that I ran, it took about 33% longer to use
front and
Le 03/07/2012 19:27, monarch_dodra a écrit :
On Tuesday, 3 July 2012 at 17:22:17 UTC, Wouter Verhelst wrote:
Jonathan M Davis jmdavisp...@gmx.com writes:
Couldn't you just overload popFront?
have a void popFront which throws off the first element without
returning anything, and an auto
Le 04/07/2012 06:32, Jonathan M Davis a écrit :
Okay, given the fact that takeFront wouldn't work with ranges like
std.stdio.ByLine, the code as proposed won't work. So, here's an adjusted
proposal:
https://github.com/jmdavis/phobos/commit/14b88d9d5528f8736ae6014013bba82367e83620
As suggested,
Le 04/07/2012 10:14, Jonathan M Davis a écrit :
On Wednesday, July 04, 2012 09:55:57 Roman D. Boiko wrote:
On Wednesday, 4 July 2012 at 04:33:14 UTC, Jonathan M Davis wrote:
If no one has any major objections to this scheme or can
provide a better proposal, I'll create a pull request from what
Many languages does this (it doesn't mean it is the right thing
to do). Do you know why this shouldn't be done ?
In C++ it was exception safety, wasn't it?
On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
I do agree with that. However, the current proposal have the
same drawback but on the code that use the range.
Both solutions are messy IMO.
What is error-prone in current client code?
If particular algorithm wants to take
On 04-Jul-12 14:50, deadalnix wrote:
Le 04/07/2012 06:32, Jonathan M Davis a écrit :
Okay, given the fact that takeFront wouldn't work with ranges like
std.stdio.ByLine, the code as proposed won't work. So, here's an adjusted
proposal:
On 07/04/2012 12:50 PM, deadalnix wrote:
Le 04/07/2012 06:32, Jonathan M Davis a écrit :
Okay, given the fact that takeFront wouldn't work with ranges like
std.stdio.ByLine, the code as proposed won't work. So, here's an adjusted
proposal:
Roman D. Boiko , dans le message (digitalmars.D:171108), a écrit :
What is error-prone in current client code?
If particular algorithm wants to take advantage of a potential
speed-up, it may decide to check whether hasConsume!Range, and
call consumeFront instead of front + popFront.
Le 04/07/2012 13:04, Roman D. Boiko a écrit :
On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
I do agree with that. However, the current proposal have the same
drawback but on the code that use the range.
Both solutions are messy IMO.
What is error-prone in current client code?
You have to maintain 2 version of you algorithm. This is more
work to test, to maintain, and it is likely to introduce more
bugs.
More code == more bugs. More NPATH = more bugs and harder to
test and to maintain.
In addition, this will result in practice in less generic code,
because one
On Wednesday, 4 July 2012 at 12:40:41 UTC, Tobias Pankrath wrote:
You have to maintain 2 version of you algorithm. This is more
work to test, to maintain, and it is likely to introduce more
bugs.
More code == more bugs. More NPATH = more bugs and harder to
test and to maintain.
In
On Wednesday, 4 July 2012 at 12:24:14 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
I am not sure what would be worse, in the long run, between
asking developpers to make front remain valid after popFront
until next call to front, or having two different standard ways
to
On 04-Jul-12 16:40, Tobias Pankrath wrote:
You have to maintain 2 version of you algorithm. This is more work to
test, to maintain, and it is likely to introduce more bugs.
More code == more bugs. More NPATH = more bugs and harder to test and
to maintain.
In addition, this will result in
On 7/4/12 8:33 AM, deadalnix wrote:
Le 04/07/2012 13:04, Roman D. Boiko a écrit :
On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
I do agree with that. However, the current proposal have the same
drawback but on the code that use the range.
Both solutions are messy IMO.
What is
Le 04/07/2012 17:17, Andrei Alexandrescu a écrit :
On 7/4/12 8:33 AM, deadalnix wrote:
Le 04/07/2012 13:04, Roman D. Boiko a écrit :
On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
I do agree with that. However, the current proposal have the same
drawback but on the code that use
On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
Many languages does this (it doesn't mean it is the right thing
to do). Do you know why this shouldn't be done ?
In C++ it was exception safety, wasn't it?
I believe that it was purely a question of speed. If popFront returns an
On Wednesday, July 04, 2012 06:42:32 Ed McCardell wrote:
On 07/04/2012 04:50 AM, Jonathan M Davis wrote:
But reducing code was never my concern (nor Dmitry's in considering
proposing essentially the same thing). It's efficiency that's the problem
- particularly with strings. IIRC, with the
On Wednesday, July 04, 2012 11:17:53 Andrei Alexandrescu wrote:
On 7/4/12 8:33 AM, deadalnix wrote:
Le 04/07/2012 13:04, Roman D. Boiko a écrit :
On Wednesday, 4 July 2012 at 10:54:41 UTC, deadalnix wrote:
I do agree with that. However, the current proposal have the same
drawback but on
IMO the root cause of this problem is something else.
The problem is that we're trying to use slices as ranges, and
they don't fit in the model.
e.g.: If you're using immutable(char)[] to represent a string,
you're /going/ to run into problems like this (like we already
have).
The right
On Wednesday, July 04, 2012 12:19:15 Jonathan M Davis wrote:
But at present, I'm seeing a performance improvement of approximately 70 -
80% in iterating over strings with consumeFront rather than front and
popFront (depending on the compiler flags and strings used).
I should clarify that. It's
On Wednesday, 4 July 2012 at 18:40:50 UTC, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
Many languages does this (it doesn't mean it is the right
thing
to do). Do you know why this shouldn't be done ?
In C++ it was exception safety, wasn't it?
I
On Wednesday, July 04, 2012 22:10:36 Tobias Pankrath wrote:
On Wednesday, 4 July 2012 at 18:40:50 UTC, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
Many languages does this (it doesn't mean it is the right
thing
to do). Do you know why this
Currently I think that idea was very bad, given that it would
be difficult to find all ranges which invalidate previous front
value on popFront.
It seems, consumeFront() is attempt to implement a forward
iterator on top of a range. Maybe the problem is mixing up two
different abstractions.
Yes. But the cost of copying the value and the cost of the
exception are
separate.
The argument is not about performance, it's about loosing values.
Simply popping off the element could throw an exception (in the
case
of strings in D, you'll get a UTFException if the string is
malformed).
On Wednesday, July 04, 2012 22:34:46 Tobias Pankrath wrote:
Yes. But the cost of copying the value and the cost of the
exception are
separate.
The argument is not about performance, it's about loosing values.
Simply popping off the element could throw an exception (in the
case
of
On Wednesday, July 04, 2012 22:26:16 RivenTheMage wrote:
Currently I think that idea was very bad, given that it would
be difficult to find all ranges which invalidate previous front
value on popFront.
It seems, consumeFront() is attempt to implement a forward
iterator on top of a range.
On Wednesday, July 04, 2012 21:39:00 Mehrdad wrote:
IMO the root cause of this problem is something else.
The problem is that we're trying to use slices as ranges, and
they don't fit in the model.
e.g.: If you're using immutable(char)[] to represent a string,
you're /going/ to run into
Le 04/07/2012 20:40, Jonathan M Davis a écrit :
On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
Many languages does this (it doesn't mean it is the right thing
to do). Do you know why this shouldn't be done ?
In C++ it was exception safety, wasn't it?
I believe that it was
Le 04/07/2012 22:34, Tobias Pankrath a écrit :
Yes. But the cost of copying the value and the cost of the exception are
separate.
The argument is not about performance, it's about loosing values.
If you implement popFront as
{
popFront(); // current popFront
return
The problem is that while in most cases, separating getting the
element referred to by the iterator (or the front of the range)
separately
from iterating is more efficient than having the iterator
return an element when
you iterate it
Yes, but iterators don't need that separation at all.
Le 04/07/2012 21:45, Jonathan M Davis a écrit :
On Wednesday, July 04, 2012 12:19:15 Jonathan M Davis wrote:
But at present, I'm seeing a performance improvement of approximately 70 -
80% in iterating over strings with consumeFront rather than front and
popFront (depending on the compiler flags
On 07/04/2012 11:53 PM, deadalnix wrote:
Le 04/07/2012 20:40, Jonathan M Davis a écrit :
On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
Many languages does this (it doesn't mean it is the right thing
to do). Do you know why this shouldn't be done ?
In C++ it was exception
On Wednesday, July 04, 2012 23:56:33 RivenTheMage wrote:
The problem is that while in most cases, separating getting the
element referred to by the iterator (or the front of the range)
separately
from iterating is more efficient than having the iterator
return an element when
you
On Thursday, July 05, 2012 00:03:02 Timon Gehr wrote:
On 07/04/2012 11:53 PM, deadalnix wrote:
Le 04/07/2012 20:40, Jonathan M Davis a écrit :
On Wednesday, July 04, 2012 12:55:44 Tobias Pankrath wrote:
Many languages does this (it doesn't mean it is the right thing
to do). Do you know
Another option would be to create a wrapper range for strings to be used when
they already have to be wrapped in another range. Functions which want to make
string processing more efficient can already specialize on strings (and often
do), so they can deal with the consumeFront issue directly
Regardless of what the final result of this discussion is, I must say that I
think that it manages to nicely highlight the benefits of discussing designs
before actually incorporating them into Phobos (or any major project). There
have been some good suggestions in this thread. The reviews for
On 7/4/12 3:19 PM, Jonathan M Davis wrote:
In theory all of these redundant operations can be done away with
optimization techniques, but probably some aren't. So we should look
first at optimizing this flow heavily before looking at an API addition
that has disadvantages in other dimensions.
On Wednesday, July 04, 2012 21:33:31 Andrei Alexandrescu wrote:
Great. Could you please post some code so we play with it? Thanks.
Okay. You can use this:
--
import std.array;
import std.conv;
import std.datetime;
import std.range;
import std.stdio;
import std.string;
import std.traits;
On 07/04/2012 10:11 PM, Jonathan M Davis wrote:
Just adjust the strings to try different strings, and adjust then number of
iterations if you need to. It prints out a two lines looking like:
ascii 82.89%: old [5 secs, 176 ms, 602 μs, and 8 hnsecs], new [4 secs, 290
ms, 683 μs, and 6 hnsecs]
On Wednesday, July 04, 2012 23:53:35 Ed McCardell wrote:
On 07/04/2012 10:11 PM, Jonathan M Davis wrote:
Just adjust the strings to try different strings, and adjust then number
of
iterations if you need to. It prints out a two lines looking like:
ascii 82.89%: old [5 secs, 176 ms,
On 7/4/12 10:11 PM, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 21:33:31 Andrei Alexandrescu wrote:
Great. Could you please post some code so we play with it? Thanks.
Okay. You can use this:
[snip]
Thanks. I made the following change to popFront:
@trusted void popFront(A)(ref A a)
On Thursday, July 05, 2012 00:04:03 Andrei Alexandrescu wrote:
On 7/4/12 10:11 PM, Jonathan M Davis wrote:
On Wednesday, July 04, 2012 21:33:31 Andrei Alexandrescu wrote:
Great. Could you please post some code so we play with it? Thanks.
Okay. You can use this:
[snip]
Thanks. I made
This seems like it probably merits a bit of discussion, so I'm bringing it up
here rather than simply opening a pull request.
At present, for some ranges (variably-lengthed ranges such as strings in
particular), calling front incurs a cost which popFront at least partially
duplicates. So, the
The name takeFront is too similar to take, which has very
different semantics.
Jonathan M Davis jmdavisp...@gmx.com writes:
This seems like it probably merits a bit of discussion, so I'm bringing it up
here rather than simply opening a pull request.
At present, for some ranges (variably-lengthed ranges such as strings in
particular), calling front incurs a cost which
On Tuesday, 3 July 2012 at 16:37:20 UTC, Jonathan M Davis wrote:
...
Oh, and if we go with this, ideally, the compiler would be
updated to use
takeFront for foreach instead of front and popFront if a range
implements it
(but still do it the current way if it doesn't). So, if
typeof(range)
On Tuesday, 3 July 2012 at 17:22:17 UTC, Wouter Verhelst wrote:
Jonathan M Davis jmdavisp...@gmx.com writes:
Couldn't you just overload popFront?
have a void popFront which throws off the first element without
returning anything, and an auto popFront which does return data.
I'd always been
consumeFront?
On Tuesday, 3 July 2012 at 17:29:45 UTC, Tobias Pankrath wrote:
consumeFront?
+1
takeFront implementation is dangerous for ranges which invalidates their
front value when popFront is called, for instance, File.byLine. Thus
takeFront will have to be used with care: any range implement takeFront
(because of the template and USFC), but it may not be valid. That makes
the
On Tuesday, July 03, 2012 19:17:40 Roman D. Boiko wrote:
The name takeFront is too similar to take, which has very
different semantics.
I have similar concerns, but takeFront and takeBack were the best that I could
come up with. frontPopFront or retPopFront and the like would be horrible. So,
On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
takeFront implementation is dangerous for ranges which invalidates their
front value when popFront is called, for instance, File.byLine. Thus
takeFront will have to be used with care: any range implement takeFront
(because of the
On Tuesday, July 03, 2012 19:29:44 Tobias Pankrath wrote:
consumeFront?
That seems like a good suggestion.
- Jonathan M Davis
On Tuesday, 3 July 2012 at 17:40:24 UTC, Jonathan M Davis wrote:
On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
takeFront implementation is dangerous for ranges which
invalidates their
front value when popFront is called, for instance,
File.byLine. Thus
takeFront will have to be
On Tuesday, July 03, 2012 10:40:07 Jonathan M Davis wrote:
On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
takeFront implementation is dangerous for ranges which invalidates their
front value when popFront is called, for instance, File.byLine. Thus
takeFront will have to be
On Tuesday, 3 July 2012 at 17:40:24 UTC, Jonathan M Davis wrote:
On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
takeFront implementation is dangerous for ranges which
invalidates their
front value when popFront is called, for instance,
File.byLine. Thus
takeFront will have to be
On Tuesday, 3 July 2012 at 18:00:55 UTC, Jonathan M Davis wrote:
On Tuesday, July 03, 2012 10:40:07 Jonathan M Davis wrote:
On Tuesday, July 03, 2012 17:31:21 Christophe Travert wrote:
takeFront implementation is dangerous for ranges which
invalidates their
front value when popFront is
1 - 100 of 106 matches
Mail list logo
