On Monday, 1 January 2018 at 02:18:36 UTC, Jonathan M Davis wrote:
Except that the reason for arrays throwing RangeErrors when you
try and index them out-of-bounds is to avoid memory safety
issues, which is not necessarily the case at all when you're
talking about ranges. Having ranges in
On Monday, 1 January 2018 at 04:18:29 UTC, Ali Çehreli wrote:
If you're fine with specifying the function as a template
argument, the following works. (As seen with 's => s.foo()'
below, you have to use a lambda for member functions anyway.)
Ali
Nice! Thanks :) And I think your usage for
On 12/30/2017 11:00 AM, aliak wrote:
Instead of this:
auto result = range.op!f;
if (!result.empty) {
result.front.method();
}
This:
range.op!f.ifFront.method();
In the above scenario I only want method to be called if the pipeline
resulted in any element left in the range.
On Sunday, December 31, 2017 01:03:17 Tony via Digitalmars-d-learn wrote:
> For me, front() should throw a pre-defined exception when called
> on an empty range in order to eliminate undefined behavior. It
> does take some time to make a check, but D does array bounds
> checking by default.
On 12/31/2017 02:14 PM, aliak wrote:
Also, is going out of array bounds well defined behavior in D even with
boundscheck off?
No. Without the checks you get undefined behavior. I.e.,
`-boundscheck=off` defeats the `@safe` attribute. For that reason, I'd
advise against ever using it.
On Sunday, 31 December 2017 at 13:14:10 UTC, aliak wrote:
On Sunday, 31 December 2017 at 01:03:17 UTC, Tony wrote:
For me, front() should throw a pre-defined exception when
called on an empty range in order to eliminate undefined
behavior. It does take some time to make a check, but D does
On Sunday, 31 December 2017 at 01:03:17 UTC, Tony wrote:
For me, front() should throw a pre-defined exception when
called on an empty range in order to eliminate undefined
behavior. It does take some time to make a check, but D does
array bounds checking by default. Ideally the front() check
For me, front() should throw a pre-defined exception when called
on an empty range in order to eliminate undefined behavior. It
does take some time to make a check, but D does array bounds
checking by default. Ideally the front() check could be turned
off somehow ("-boundschecks=off") by the
On Saturday, 30 December 2017 at 19:00:07 UTC, aliak wrote:
Instead of this:
auto result = range.op!f;
if (!result.empty) {
result.front.method();
}
This:
range.op!f.ifFront.method();
Ah, so you don't have a problem with checking emptiness but you
want to do it inside the
On Saturday, December 30, 2017 19:11:20 aliak via Digitalmars-d-learn wrote:
> On Friday, 29 December 2017 at 20:33:22 UTC, Jonathan M Davis
>
> wrote:
> > Well, I don't know what you're really doing in code here, but
> > in general, you'd write your code in a way that it checks empty
> > and
On Saturday, 30 December 2017 at 19:00:07 UTC, aliak wrote:
On Friday, 29 December 2017 at 20:47:44 UTC, Dukc wrote:
[...]
Hmm, interesting. Not sure that's what I'm looking for but I
like it anyway :)
I'm more looking to deal with situations like this:
Instead of this:
auto result =
On Friday, 29 December 2017 at 20:33:22 UTC, Jonathan M Davis
wrote:
Well, I don't know what you're really doing in code here, but
in general, you'd write your code in a way that it checks empty
and simply doesn't try to do anything with front if the range
is empty.
Yes, ideally, if
On Friday, 29 December 2017 at 20:47:44 UTC, Dukc wrote:
On Friday, 29 December 2017 at 19:38:44 UTC, aliak wrote:
So when I'm dealing with ranges, there're a number of times
where I get the front of the returned result of a set of
operations, but of course there is no front so you get an
On Friday, 29 December 2017 at 20:11:03 UTC, Seb wrote:
On Friday, 29 December 2017 at 19:38:44 UTC, aliak wrote:
Hi,
So when I'm dealing with ranges, there're a number of times
where I get the front of the returned result of a set of
operations, but of course there is no front so you get an
On Friday, 29 December 2017 at 19:38:44 UTC, aliak wrote:
So when I'm dealing with ranges, there're a number of times
where I get the front of the returned result of a set of
operations, but of course there is no front so you get an
runtime access error.
This could be what you want:
auto
On Friday, December 29, 2017 19:38:44 aliak via Digitalmars-d-learn wrote:
> Hi,
>
> So when I'm dealing with ranges, there're a number of times where
> I get the front of the returned result of a set of operations,
> but of course there is no front so you get an runtime access
> error.
You don't
On Friday, 29 December 2017 at 19:38:44 UTC, aliak wrote:
Hi,
So when I'm dealing with ranges, there're a number of times
where I get the front of the returned result of a set of
operations, but of course there is no front so you get an
runtime access error.
[...]
Do you know about the
17 matches
Mail list logo
