On Sat, 29 Mar 2014 17:02:30 -0400, Marc Schütz schue...@gmx.net wrote:
On Saturday, 29 March 2014 at 01:36:46 UTC, Steven Schveighoffer wrote:
On Fri, 28 Mar 2014 07:47:22 -0400, Marc Schütz schue...@gmx.net
wrote:
On Thursday, 27 March 2014 at 16:12:36 UTC, monarch_dodra wrote:
If you
On Fri, 28 Mar 2014 22:23:29 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 3/28/2014 3:42 AM, Steven Schveighoffer wrote:
I'm also curious what a generic read() should do when the stream is
empty.
Returns 0 elements read.
Meaning it must also write through a pointer if it
On Fri, 28 Mar 2014 00:58:35 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Following the protocol empty-front-popFront always works.
Where the differences come in is when people skip calling empty.
-- when it is known empty will return false through logical deduction.
-Steve
On Monday, 31 March 2014 at 11:40:11 UTC, Steven Schveighoffer
wrote:
Blocking operations may have a noticeable impact, but they may
not. It depends on what you do between construction and
processing.
For example, if you have:
foreach(l; stdin.byLine)
Lazily fetching the first line makes no
On Mon, 31 Mar 2014 13:43:05 -0400, Marc Schütz schue...@gmx.net wrote:
I've found the example I was talking about:
http://forum.dlang.org/thread/mailman.323.1393458346.6445.digitalmar...@puremagic.com
I misremembered, filter wasn't even involved. But similar situations may
arise from using
On Saturday, 29 March 2014 at 09:06:45 UTC, monarch_dodra wrote:
On Saturday, 29 March 2014 at 00:14:40 UTC, Andrei Alexandrescu
wrote:
It increasingly seems to me we need to do this. -- Andrei
Question: Should this new restriction only be applied to
*Input*Ranges? If so, then it might make
On Friday, 28 March 2014 at 23:14:56 UTC, Tobias Müller wrote:
On Thursday, 27 March 2014 at 20:49:16 UTC, Walter Bright wrote:
On 3/27/2014 12:21 PM, Rainer Schuetze wrote:
This loop is intuitive. Not being allowed to call empty or
front multiple times
or not at all is unintuitive. They
On Saturday, 29 March 2014 at 00:14:40 UTC, Andrei Alexandrescu
wrote:
It increasingly seems to me we need to do this. -- Andrei
What I find funny here is that walter is saying we must enforce
that empty always be called in the range - for performance.
Yet about a year ago, he made a
29-Mar-2014 06:47, Andrei Alexandrescu пишет:
On 3/28/14, 11:40 AM, Dmitry Olshansky wrote:
28-Mar-2014 22:29, Walter Bright пишет:
On 3/28/2014 10:11 AM, Dmitry Olshansky wrote:
WAT? The overhead is in issuing system calls, you'd want to do as
little of them
as possible. Reading byte by byte
29-Mar-2014 02:05, Walter Bright пишет:
On 3/28/2014 11:40 AM, Dmitry Olshansky wrote:
Which uses C's BUFFERED I/O and it reads from it byte by byte via
getc. Even
though sys calls are amortized by C runtime, we have a function call
per byte.
No wonder it's SLOW.
How about a PR to fix it?
On Saturday, 29 March 2014 at 00:14:40 UTC, Andrei Alexandrescu
wrote:
It increasingly seems to me we need to do this. -- Andrei
Question: Should this new restriction only be applied to
*Input*Ranges? If so, then it might make more sense.
Ranges that also satisfy the *Forward* interface
On Sunday, 23 March 2014 at 00:50:34 UTC, Walter Bright wrote:
It's become clear to me that we've underspecified what an
InputRange is.
As someone who has missed this discussion, can I just say this:
can we please document the result somewhere, and possibly even
announce it clearly so that
On Saturday, 29 March 2014 at 01:36:46 UTC, Steven Schveighoffer
wrote:
On Fri, 28 Mar 2014 07:47:22 -0400, Marc Schütz
schue...@gmx.net wrote:
On Thursday, 27 March 2014 at 16:12:36 UTC, monarch_dodra
wrote:
If you initialized the next element in both constructor and
popFront, then you'd get
Am Fri, 28 Mar 2014 19:23:29 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 3/28/2014 3:42 AM, Steven Schveighoffer wrote:
I'm also curious what a generic read() should do when the stream is empty.
Returns 0 elements read.
I guess we all have a clear concept of streams in our
Luís Marques wrote in message
news:exmfmqftpykoaxdgl...@forum.dlang.org...
- Is it allowed for an InputRange to become empty and then not empty
again? For a finite RandomAccessRange to increase in length? E.g.:
Not by itself - if a range's empty has returned true, calling empty
repeatedly
On Friday, 28 March 2014 at 02:14:40 UTC, H. S. Teoh wrote:
I'm with Walter on this one. Generic code should NOT assume
anything
about a range it was given, and therefore it should call .empty
before
calling .front or .popFront. If you know that a particular
range
doesn't require calling
Am Thu, 27 Mar 2014 17:20:25 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 3/27/2014 2:56 PM, Andrei Alexandrescu wrote:
On 3/27/14, 2:24 PM, Walter Bright wrote:
The range protocol is designed to work with streams.
It's designed to work with containers.
I know we talked
On Friday, 28 March 2014 at 00:41:42 UTC, Walter Bright wrote:
On 3/27/2014 3:23 PM, QAston wrote:
The protocol is not intuitive.
I find empty-front-popFront as perfectly intuitive. I don't
find the counter proposals, which come with baggage like
constructors that may fail, and front() that
On Thursday, 27 March 2014 at 21:54:00 UTC, Andrei Alexandrescu
wrote:
On 3/27/14, 1:58 PM, Walter Bright wrote:
On 3/27/2014 12:50 PM, Andrei Alexandrescu wrote:
Yah, agreed. -- Andrei
Completely unworkable. To determine if a range is empty or
not, it may
have to actually read from its
On Fri, 28 Mar 2014 08:59:34 -, Paolo Invernizzi
paolo.invernizzi@no.address wrote:
For what concern us, everyone here is happy with the fact that empty
*must* be checked prior to front/popFront.
This is actually not true.
R
--
Using Opera's revolutionary email client:
On 3/28/2014 1:32 AM, Johannes Pfau wrote:
Ranges have equivalents in other languages:
iterators in c++,
IEnumerator in c#,
Iterator in java
all these languages have special stream types for raw data. I don't
think it's bad if we also have streams/ranges separate in D.
Do you see a point to
On Thu, 27 Mar 2014 20:25:56 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 3/27/2014 2:31 PM, Steven Schveighoffer wrote:
Adding range primitives on top of a stream does not make sense.
Are ready to implement a parallel universe of stream based algorithms to
go alongside all
On Thursday, 27 March 2014 at 16:12:36 UTC, monarch_dodra wrote:
On Thursday, 27 March 2014 at 15:45:14 UTC, Andrei Alexandrescu
wrote:
On 3/27/14, 8:44 AM, Steven Schveighoffer wrote:
On Thu, 27 Mar 2014 11:40:59 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/27/14,
On Friday, 28 March 2014 at 04:58:28 UTC, Walter Bright wrote:
On 3/27/2014 3:21 AM, Chris wrote:
I agree. I've been using ranges for a while now and have tried
different implementations based on advice given on this forum
and
depending on each case. After reading this thread I looked at
some
I think something has gone wrong in this discussion somewhere. It
is like this.
Do not assume .empty is const, this is unreasonable.
Do not assume .front is const, this is unreasonable.
.popFront has the only high-level observable difference in
removing something from the front of an
On Fri, 28 Mar 2014 14:15:10 -, Chris wend...@tcd.ie wrote:
Earlier Walter wrote:
I don't like being in the position of when I need high performance
code, I have
to implement my own ranges algorithms, or telling customers they need
to do so.
I don't think there is a one size fits
On Friday, 28 March 2014 at 15:49:06 UTC, Regan Heath wrote:
On Fri, 28 Mar 2014 14:15:10 -, Chris wend...@tcd.ie
wrote:
Earlier Walter wrote:
I don't like being in the position of when I need high
performance code, I have
to implement my own ranges algorithms, or telling customers
On Fri, 28 Mar 2014 16:30:36 -, John Stahara
john.stahara+dl...@gmail.com wrote:
On Fri, 28 Mar 2014 16:23:11 +, Paolo Invernizzi wrote:
On Friday, 28 March 2014 at 09:30:25 UTC, Regan Heath wrote:
On Fri, 28 Mar 2014 08:59:34 -, Paolo Invernizzi
paolo.invernizzi@no.address
28-Mar-2014 13:55, Walter Bright пишет:
On 3/28/2014 1:32 AM, Johannes Pfau wrote:
Ranges have equivalents in other languages:
iterators in c++,
IEnumerator in c#,
Iterator in java
all these languages have special stream types for raw data. I don't
think it's bad if we also have streams/ranges
On Fri, 28 Mar 2014 16:04:29 -, Chris wend...@tcd.ie wrote:
On Friday, 28 March 2014 at 15:49:06 UTC, Regan Heath wrote:
On Fri, 28 Mar 2014 14:15:10 -, Chris wend...@tcd.ie wrote:
Earlier Walter wrote:
I don't like being in the position of when I need high performance
code, I
Am Fri, 28 Mar 2014 02:55:45 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 3/28/2014 1:32 AM, Johannes Pfau wrote:
Ranges have equivalents in other languages:
iterators in c++,
IEnumerator in c#,
Iterator in java
all these languages have special stream types for raw
On Fri, Mar 28, 2014 at 04:30:36PM +, John Stahara wrote:
On Fri, 28 Mar 2014 16:23:11 +, Paolo Invernizzi wrote:
On Friday, 28 March 2014 at 09:30:25 UTC, Regan Heath wrote:
On Fri, 28 Mar 2014 08:59:34 -, Paolo Invernizzi
paolo.invernizzi@no.address wrote:
For what concern
28-Mar-2014 04:20, Walter Bright пишет:
On 3/27/2014 2:56 PM, Andrei Alexandrescu wrote:
On 3/27/14, 2:24 PM, Walter Bright wrote:
The range protocol is designed to work with streams.
It's designed to work with containers.
I know we talked about streams when we designed it.
If streams
On Friday, 28 March 2014 at 09:30:25 UTC, Regan Heath wrote:
On Fri, 28 Mar 2014 08:59:34 -, Paolo Invernizzi
paolo.invernizzi@no.address wrote:
For what concern us, everyone here is happy with the fact that
empty *must* be checked prior to front/popFront.
This is actually not true.
R
On Friday, 28 March 2014 at 16:59:05 UTC, Johannes Pfau wrote:
It 'works' with streams but it's way too slow. You don't want
to read
byte-per-byte. Of course you can always implement ranges on top
of
streams. Usually these will not provide byte-per-byte access but
efficient higher level
On Fri, 28 Mar 2014 16:23:11 +, Paolo Invernizzi wrote:
On Friday, 28 March 2014 at 09:30:25 UTC, Regan Heath wrote:
On Fri, 28 Mar 2014 08:59:34 -, Paolo Invernizzi
paolo.invernizzi@no.address wrote:
For what concern us, everyone here is happy with the fact that empty
*must* be
28-Mar-2014 21:07, Walter Bright пишет:
On 3/28/2014 9:48 AM, Dmitry Olshansky wrote:
28-Mar-2014 13:55, Walter Bright пишет:
On 3/28/2014 1:32 AM, Johannes Pfau wrote:
Ranges have equivalents in other languages:
iterators in c++,
IEnumerator in c#,
Iterator in java
all these languages have
On 3/28/2014 9:48 AM, Dmitry Olshansky wrote:
28-Mar-2014 13:55, Walter Bright пишет:
On 3/28/2014 1:32 AM, Johannes Pfau wrote:
Ranges have equivalents in other languages:
iterators in c++,
IEnumerator in c#,
Iterator in java
all these languages have special stream types for raw data. I
Am Fri, 28 Mar 2014 17:22:26 +
schrieb w0rp devw...@gmail.com:
I think a key is to offer something with gives you chunks at a
time right at the top, and the use .joiner on that. I read files
this way currently.
auto fileByteRange = File(something).byChunk(chunkSize).joiner;
Earlier Walter wrote:
I don't like being in the position of when I need high
performance code, I have
to implement my own ranges algorithms, or telling customers
they need to do so.
I don't think there is a one size fits all. What if customers ask
for maximum security? In any language, if
On 3/28/2014 10:11 AM, Dmitry Olshansky wrote:
WAT? The overhead is in issuing system calls, you'd want to do as little of them
as possible. Reading byte by byte is an exemplar of idiocy in I/O code.
That's why we have things like byLine().
On Friday, 28 March 2014 at 08:34:08 UTC, Johannes Pfau wrote:
Am Thu, 27 Mar 2014 17:20:25 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 3/27/2014 2:56 PM, Andrei Alexandrescu wrote:
On 3/27/14, 2:24 PM, Walter Bright wrote:
The range protocol is designed to work with streams.
28-Mar-2014 22:29, Walter Bright пишет:
On 3/28/2014 10:11 AM, Dmitry Olshansky wrote:
WAT? The overhead is in issuing system calls, you'd want to do as
little of them
as possible. Reading byte by byte is an exemplar of idiocy in I/O code.
That's why we have things like byLine().
Which
On Friday, 28 March 2014 at 16:30:36 UTC, John Stahara wrote:
On Fri, 28 Mar 2014 16:23:11 +, Paolo Invernizzi wrote:
On Friday, 28 March 2014 at 09:30:25 UTC, Regan Heath wrote:
On Fri, 28 Mar 2014 08:59:34 -, Paolo Invernizzi
paolo.invernizzi@no.address wrote:
For what concern us,
On 3/28/2014 11:40 AM, Dmitry Olshansky wrote:
Which uses C's BUFFERED I/O and it reads from it byte by byte via getc. Even
though sys calls are amortized by C runtime, we have a function call per byte.
No wonder it's SLOW.
How about a PR to fix it?
On Thursday, 27 March 2014 at 20:49:16 UTC, Walter Bright wrote:
On 3/27/2014 12:21 PM, Rainer Schuetze wrote:
This loop is intuitive. Not being allowed to call empty or
front multiple times
or not at all is unintuitive. They should not be named as if
they are properties
then.
I can concede
On Friday, 28 March 2014 at 23:14:56 UTC, Tobias Müller wrote:
On Thursday, 27 March 2014 at 20:49:16 UTC, Walter Bright wrote:
On 3/27/2014 12:21 PM, Rainer Schuetze wrote:
This loop is intuitive. Not being allowed to call empty or
front multiple times
or not at all is unintuitive. They
On 3/28/14, 3:42 AM, Steven Schveighoffer wrote:
On Thu, 27 Mar 2014 20:25:56 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 3/27/2014 2:31 PM, Steven Schveighoffer wrote:
Adding range primitives on top of a stream does not make sense.
Are ready to implement a parallel universe
On Friday, 28 March 2014 at 22:05:33 UTC, Walter Bright wrote:
On 3/28/2014 11:40 AM, Dmitry Olshansky wrote:
Which uses C's BUFFERED I/O and it reads from it byte by byte
via getc. Even
though sys calls are amortized by C runtime, we have a
function call per byte.
No wonder it's SLOW.
How
On Friday, 28 March 2014 at 23:14:56 UTC, Tobias Müller wrote:
On Thursday, 27 March 2014 at 20:49:16 UTC, Walter Bright wrote:
On 3/27/2014 12:21 PM, Rainer Schuetze wrote:
This loop is intuitive. Not being allowed to call empty or
front multiple times
or not at all is unintuitive. They
On Fri, 28 Mar 2014 20:14:39 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/28/14, 3:42 AM, Steven Schveighoffer wrote:
On Thu, 27 Mar 2014 20:25:56 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 3/27/2014 2:31 PM, Steven Schveighoffer wrote:
Adding range
On Thu, 27 Mar 2014 19:52:52 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 3/27/2014 2:46 PM, Steven Schveighoffer wrote:
What I am protesting is the idea that you *know* input exists, you must
still call empty.
Front is enough in that case.
You can't use that on generic
On Fri, 28 Mar 2014 07:47:22 -0400, Marc Schütz schue...@gmx.net wrote:
On Thursday, 27 March 2014 at 16:12:36 UTC, monarch_dodra wrote:
I call shenanigans. This is the code:
@property bool empty()
{
if (nLeft)
return false;
On 3/28/2014 3:42 AM, Steven Schveighoffer wrote:
I'm also curious what a generic read() should do when the stream is empty.
Returns 0 elements read.
Meaning it must also write through a pointer if it did read something.
How is that faster than a 1 element buffer?
On 3/28/14, 11:40 AM, Dmitry Olshansky wrote:
28-Mar-2014 22:29, Walter Bright пишет:
On 3/28/2014 10:11 AM, Dmitry Olshansky wrote:
WAT? The overhead is in issuing system calls, you'd want to do as
little of them
as possible. Reading byte by byte is an exemplar of idiocy in I/O code.
That's
On Wednesday, March 26, 2014 10:36:08 Andrei Alexandrescu wrote:
On 3/26/14, 8:37 AM, Steven Schveighoffer wrote:
On Wed, 26 Mar 2014 11:09:04 -0400, Regan Heath re...@netmail.co.nz
wrote:
On Wed, 26 Mar 2014 12:30:53 -, Steven Schveighoffer
schvei...@yahoo.com wrote:
Gah, I
On 27.03.2014 03:48, Walter Bright wrote:
On 3/26/2014 7:19 PM, Steven Schveighoffer wrote:
if(!r.empty)
{
auto r2 = map!(x = x * 2)(r);
do
{
auto x = r2.front;
...
} while(!r2.empty);
}
Should we be required to re-verify that r2 is not empty before using
it? It
On 27.03.2014 07:53, Rainer Schuetze wrote:
bool empty() {
if(_cached) return false;
_cache = getc!T();
return (_cache 0);
}
Ouch, pasted before fixing:
bool empty() {
if(_cached) return false;
_cache = getc!T();
_cached = _cache = 0; // this line added
On Wednesday, 26 March 2014 at 18:04:44 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 26 March 2014 at 17:36:08 UTC, Andrei
Alexandrescu wrote:
I think requiring users to call empty before front on input
ranges is a concession we should make.
Then the name should change to ready. It makes
On 3/26/2014 11:53 PM, Rainer Schuetze wrote:
IIUC what you are proposing would be covered better by removing front and return
the value by popFront.
Different things being ranged over make different decisions as to what goes into
each function.
Instead of forcing strong, breaking and
On 3/26/2014 11:53 PM, Rainer Schuetze wrote:
This caching range example:
///
T getc(T)();
struct irange(T)
{
bool _cached;
T _cache;
this(T[] arr) { _cached = false; }
bool empty() {
if(_cached) return false;
_cache = getc!T();
On 3/26/2014 11:48 PM, Jonathan M Davis wrote:
However, it seems really off to me for there to be any real work going on in
empty,
Many things, like some ttys, can not be tested for being empty without reading
it, and reading of a tty is destructive.
and I'd be leery of any range which
On Sunday, 23 March 2014 at 01:07:27 UTC, Rikki Cattermole wrote:
On Sunday, 23 March 2014 at 00:50:34 UTC, Walter Bright wrote:
It's become clear to me that we've underspecified what an
InputRange is. The normal way to use it is:
while (!r.empty) {
auto e = r.front;
... do
On Thu, 27 Mar 2014 02:44:13 -, Daniel Murphy
yebbliesnos...@gmail.com wrote:
Regan Heath wrote in message
news:op.xdb9a9v354x...@puck.auriga.bhead.co.uk...
What guarantees range2 is longer than range1? The isArray case checks
explicitly, but the generic one doesn't. Is it a
On Thursday, 27 March 2014 at 04:17:16 UTC, Walter Bright wrote:
On 3/26/2014 7:55 PM, Steven Schveighoffer wrote:
OK, but it's logical to assume you *can* avoid a call to empty
if you know
what's going on under the hood, no? Then at that point, you
have lost the
requirement -- people will
On Thu, 27 Mar 2014 02:19:13 -, Steven Schveighoffer
schvei...@yahoo.com wrote:
if(!r.empty)
{
auto r2 = map!(x = x * 2)(r);
do
{
auto x = r2.front;
...
} while(!r2.empty);
}
if(r.empty)
return;
auto r2 = map!(x = x * 2)(r);
while(!r2.empty)
{
auto x =
On Thu, 27 Mar 2014 10:49:42 -, Marc Schütz schue...@gmx.net wrote:
On Thursday, 27 March 2014 at 04:17:16 UTC, Walter Bright wrote:
On 3/26/2014 7:55 PM, Steven Schveighoffer wrote:
OK, but it's logical to assume you *can* avoid a call to empty if you
know
what's going on under the
On Thursday, 27 March 2014 at 08:13:28 UTC, Paulo Pinto wrote:
Why not?
It is how iterators work in most OO languages.
Why not what? A query for empty() should not have any side
effects. In what library does that happen? Tests should in
general not have side effects unless the name suggest
On Thu, 27 Mar 2014 00:17:21 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 3/26/2014 7:55 PM, Steven Schveighoffer wrote:
OK, but it's logical to assume you *can* avoid a call to empty if you
know
what's going on under the hood, no? Then at that point, you have lost
the
On Thursday, 27 March 2014 at 12:35:04 UTC, Steven Schveighoffer
wrote:
What happens when one of our clients code breaks severely
because we make a change in phobos that assumes empty is always
called first on a newly-created range?
You probably can run-time test this in Debug builds, but…
I
On 3/27/14, 3:49 AM, Marc Schütz schue...@gmx.net wrote:
I was originally going to do that, but then I took a closer look at the
documentation, which says ([1] in the documentation of `isInputRange()`):
Calling r.front is allowed only if calling r.empty has, or would have,
returned false.
On 3/27/14, 5:35 AM, Steven Schveighoffer wrote:
BTW, I think there has been recent talk about not focusing on dust when
we are laying bricks. This would have my vote as useless dust. This does
not solve the problem of streams-as-ranges, because streams don't make
good ranges. It doesn't really
On Thu, 27 Mar 2014 11:19:15 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/27/14, 3:49 AM, Marc Schütz schue...@gmx.net wrote:
I was originally going to do that, but then I took a closer look at the
documentation, which says ([1] in the documentation of
On Thu, 27 Mar 2014 11:40:59 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/27/14, 5:35 AM, Steven Schveighoffer wrote:
BTW, I think there has been recent talk about not focusing on dust when
we are laying bricks. This would have my vote as useless dust. This does
not
On 3/27/14, 8:44 AM, Steven Schveighoffer wrote:
At the moment, the only candidates I can think of are lazy caching
ranges. How many of those exist?
filter comes to mind. -- Andrei
On 3/27/14, 8:44 AM, Steven Schveighoffer wrote:
On Thu, 27 Mar 2014 11:40:59 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/27/14, 5:35 AM, Steven Schveighoffer wrote:
BTW, I think there has been recent talk about not focusing on dust when
we are laying bricks. This
On Thursday, 27 March 2014 at 15:19:37 UTC, Andrei Alexandrescu
wrote:
On 3/27/14, 3:49 AM, Marc Schütz schue...@gmx.net wrote:
I was originally going to do that, but then I took a closer
look at the
documentation, which says ([1] in the documentation of
`isInputRange()`):
Calling r.front is
On Thursday, 27 March 2014 at 15:45:14 UTC, Andrei Alexandrescu
wrote:
On 3/27/14, 8:44 AM, Steven Schveighoffer wrote:
On Thu, 27 Mar 2014 11:40:59 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/27/14, 5:35 AM, Steven Schveighoffer wrote:
BTW, I think there has been
On Sunday, 23 March 2014 at 00:50:34 UTC, Walter Bright wrote:
It's become clear to me that we've underspecified what an
InputRange is.
Some thoughts:
- A while ago I realized I did not know how some of those
underspecified details should be implemented (I think my initial
doubt was if the
On Thu, 27 Mar 2014 12:02:16 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Thursday, 27 March 2014 at 15:19:37 UTC, Andrei Alexandrescu wrote:
On 3/27/14, 3:49 AM, Marc Schütz schue...@gmx.net wrote:
I was originally going to do that, but then I took a closer look at the
On 3/27/14, 9:12 AM, monarch_dodra wrote:
filter comes to mind. -- Andrei
You *just* turned down a pull that did exactly that, for exactly the
same reasons.
I was on the verge, and we need to discuss this more. A constructor that
does arbitrary work for a lazy range doesn't sit well. --
On Thursday, 27 March 2014 at 19:03:26 UTC, Andrei Alexandrescu
wrote:
On 3/27/14, 9:12 AM, monarch_dodra wrote:
filter comes to mind. -- Andrei
You *just* turned down a pull that did exactly that, for
exactly the
same reasons.
I was on the verge, and we need to discuss this more. A
On 27.03.2014 09:42, Walter Bright wrote:
On 3/26/2014 11:53 PM, Rainer Schuetze wrote:
IIUC what you are proposing would be covered better by removing front
and return
the value by popFront.
Different things being ranged over make different decisions as to what
goes into each function.
On 27.03.2014 10:06, Walter Bright wrote:
On 3/26/2014 11:53 PM, Rainer Schuetze wrote:
This caching range example:
///
T getc(T)();
struct irange(T)
{
bool _cached;
T _cache;
this(T[] arr) { _cached = false; }
bool empty() {
if(_cached)
On 3/27/14, 11:53 AM, Steven Schveighoffer wrote:
On Thu, 27 Mar 2014 12:02:16 -0400, monarch_dodra
monarchdo...@gmail.com wrote:
On Thursday, 27 March 2014 at 15:19:37 UTC, Andrei Alexandrescu wrote:
On 3/27/14, 3:49 AM, Marc Schütz schue...@gmx.net wrote:
I was originally going to do that,
On 3/27/2014 12:24 PM, Rainer Schuetze wrote:
The caller is told to guarantee that empty must not return true.
I think that is the very definition of looking under the hood in order to
violate protocol. A range CANNOT be written generically and support that.
On 3/27/2014 12:21 PM, Rainer Schuetze wrote:
This loop is intuitive. Not being allowed to call empty or front multiple times
or not at all is unintuitive. They should not be named as if they are properties
then.
I can concede that. But I can't concede being able to call front without first
On 3/27/2014 9:12 AM, monarch_dodra wrote:
If you initialized the next element in both constructor
As mentioned earlier, requiring this of a range constructor makes it impossible
to separate composition of a range with using it.
As also mentioned earlier, this throws under the bus entire
On 3/27/2014 3:49 AM, Marc Schütz schue...@gmx.net wrote:
I was originally going to do that, but then I took a closer look at the
documentation, which says ([1] in the documentation of `isInputRange()`):
Calling r.front is allowed only if calling r.empty has, or would have, returned
false.
On 3/27/2014 12:50 PM, Andrei Alexandrescu wrote:
Yah, agreed. -- Andrei
Completely unworkable. To determine if a range is empty or not, it may have to
actually read from its input. TTYs are an example. Although empty may then cache
the result, and not read the second time it is called, an
On Thu, 27 Mar 2014 16:53:35 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 3/27/2014 9:12 AM, monarch_dodra wrote:
If you initialized the next element in both constructor
As mentioned earlier, requiring this of a range constructor makes it
impossible to separate composition
On 3/27/2014 5:45 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 27 March 2014 at 12:35:04 UTC, Steven Schveighoffer wrote:
I think we should work on making a protocol that does not require awkward
calls, rather than alienating developers who don't follow the
On Thu, 27 Mar 2014 16:58:12 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 3/27/2014 12:50 PM, Andrei Alexandrescu wrote:
Yah, agreed. -- Andrei
Completely unworkable. To determine if a range is empty or not, it may
have to actually read from its input. TTYs are an example.
On Thu, 27 Mar 2014 17:06:35 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 3/27/2014 5:45 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 27 March 2014 at 12:35:04 UTC, Steven Schveighoffer wrote:
I think we should work on making a protocol that
On 3/27/2014 2:13 PM, Steven Schveighoffer wrote:
Note that a stream makes a terrible range, simply because of what you say --
reading is destructive, and determining emptiness is dependent on reading. You
need a buffered stream to make a good range, and then the logic becomes much
more
On 3/27/2014 1:59 PM, Steven Schveighoffer wrote:
On Thu, 27 Mar 2014 16:53:35 -0400, Walter Bright newshou...@digitalmars.com
wrote:
On 3/27/2014 9:12 AM, monarch_dodra wrote:
If you initialized the next element in both constructor
As mentioned earlier, requiring this of a range
On Thu, 27 Mar 2014 17:24:11 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 3/27/2014 2:13 PM, Steven Schveighoffer wrote:
Note that a stream makes a terrible range, simply because of what you
say --
reading is destructive, and determining emptiness is dependent on
reading. You
On Thu, 27 Mar 2014 17:28:05 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 3/27/2014 1:59 PM, Steven Schveighoffer wrote:
On Thu, 27 Mar 2014 16:53:35 -0400, Walter Bright
newshou...@digitalmars.com
wrote:
On 3/27/2014 9:12 AM, monarch_dodra wrote:
If you initialized the
On 3/27/14, 1:58 PM, Walter Bright wrote:
On 3/27/2014 12:50 PM, Andrei Alexandrescu wrote:
Yah, agreed. -- Andrei
Completely unworkable. To determine if a range is empty or not, it may
have to actually read from its input. TTYs are an example. Although
empty may then cache the result, and
On 3/27/14, 2:24 PM, Walter Bright wrote:
The range protocol is designed to work with streams.
It's designed to work with containers.
It's a giant fail
if they do not, or if you want to create a separate, non-range universe
to deal with streams.
It's not a giant fail, we just need to
1 - 100 of 164 matches
Mail list logo
