The following code:
import std.range;
void main()
{
auto i = iota(3);
writeln(i.front, ", length: ", i.length); i.popFront();
writeln(i.front, ", length: ", i.length); i.popFront();
writeln(i.front, ", length: ", i.length); i.popFront();
writeln
Brad Anderson:
You can popFront() for as long as you want well passed the
length. Obviously popping off the front of a zero length range
isn't valid but I would have expected a range violation to
occur rather than it to silently continuing the series with a
wrapped around length.
I think it'
On Thursday, 19 April 2012 at 03:37:00 UTC, bearophile wrote:
Brad Anderson:
You can popFront() for as long as you want well passed the
length. Obviously popping off the front of a zero length range
isn't valid but I would have expected a range violation to
occur rather than it to silently con
On Thursday, April 19, 2012 05:45:54 Brad Anderson wrote:
> Doing this same thing to a slice of an array does throw a Range
> Violation exception in release (and asserts in debug).
That's impossible for a library to do. There is no way to version code on
whether it's in release mode or not. Only
On 04/18/2012 08:45 PM, Brad Anderson wrote:
> On Thursday, 19 April 2012 at 03:37:00 UTC, bearophile wrote:
>> Brad Anderson:
>>> You can popFront() for as long as you want well passed the length.
>>> Obviously popping off the front of a zero length range isn't valid
>>> but I would have expected
Le 19/04/2012 05:36, bearophile a écrit :
> Brad Anderson:
>> You can popFront() for as long as you want well passed the length.
>> Obviously popping off the front of a zero length range isn't valid but
>> I would have expected a range violation to occur rather than it to
>> silently continuing the
On Thursday, April 19, 2012 09:58:00 Somedude wrote:
> Le 19/04/2012 05:36, bearophile a écrit :
> > Brad Anderson:
> >> You can popFront() for as long as you want well passed the length.
> >> Obviously popping off the front of a zero length range isn't valid but
> >> I would have expected a range
Le 19/04/2012 10:07, Jonathan M Davis a écrit :
> Having an assertion may be desirable, but the bug is in the usage of iota,
> not
> iota itself. At best, the assertion would help indicate that the caller has a
> bug. It's exactly the same as doing something like
>
> for(size_t i = 3; cond; --i
On Thursday, April 19, 2012 10:14:39 Somedude wrote:
> Le 19/04/2012 10:07, Jonathan M Davis a écrit :
> > Having an assertion may be desirable, but the bug is in the usage of iota,
> > not iota itself. At best, the assertion would help indicate that the
> > caller has a bug. It's exactly the same
Le 19/04/2012 11:11, Jonathan M Davis a écrit :
> On Thursday, April 19, 2012 10:14:39 Somedude wrote:
>> Le 19/04/2012 10:07, Jonathan M Davis a écrit :
>>> Having an assertion may be desirable, but the bug is in the usage of iota,
>>> not iota itself. At best, the assertion would help indicate th
On Thu, 19 Apr 2012 04:07:00 -0400, Jonathan M Davis
wrote:
Having an assertion may be desirable, but the bug is in the usage of
iota, not
iota itself.
Yes, and iota should detect that bug with an assert. No case can really
be made that iota shouldn't be changed. Please file an enhanc
On Thursday, 19 April 2012 at 11:38:39 UTC, Steven Schveighoffer
wrote:
On Thu, 19 Apr 2012 04:07:00 -0400, Jonathan M Davis
wrote:
Having an assertion may be desirable, but the bug is in the
usage of iota, not
iota itself.
Yes, and iota should detect that bug with an assert. No case
can
On Thursday, 19 April 2012 at 12:39:25 UTC, SomeDude wrote:
On Thursday, 19 April 2012 at 11:38:39 UTC, Steven
Schveighoffer wrote:
On Thu, 19 Apr 2012 04:07:00 -0400, Jonathan M Davis
wrote:
Having an assertion may be desirable, but the bug is in the
usage of iota, not
iota itself.
Yes,
13 matches
Mail list logo
