On 6/15/21 12:24 AM, surlymoor wrote:
All my custom range types perform all their meaningful work in their
respective popFront methods, in addition to its expected source data
iteration duties. The reason I do this is because I swear I read in a
github discussion that front is expected to be
On Tue, Jun 15, 2021 at 02:20:11PM +, Paul Backus via Digitalmars-d-learn
wrote:
[...]
> It's a time-space tradeoff. As you say, caching requires additional
> space to store the cached element. On the other hand, *not* caching
> means that you spend unnecessary time computing the next element
On Tuesday, 15 June 2021 at 04:24:09 UTC, surlymoor wrote:
All my custom range types perform all their meaningful work in
their respective popFront methods, in addition to its expected
source data iteration duties. The reason I do this is because I
swear I read in a github discussion that
On 6/14/21 10:17 PM, mw wrote:
> I think there is another convention (although it's not formally
> enforced, but should be) is:
>
> -- `obj.front() [should be] const`, i.e. it shouldn't modify `obj`, so
> can be called multiple times at any given state, and produce the same
> result
In other
On Tuesday, 15 June 2021 at 04:24:09 UTC, surlymoor wrote:
At the moment, I feel that as long as the stashed front element
isn't too "big" (For some definition of big, I guess.), that
built-in caching should be fine. But is this acceptable? What's
the best practice for determining which
On 15.06.21 07:17, mw wrote:
https://dlang.org/library/std/range/primitives/front.html
the 2nd decl:
dchar front(T) (
scope const(T)[] a
) pure @property @safe
if (isAutodecodableString!(T[]));
you can see `const`
but
https://dlang.org/library/std/range/primitives/pop_front.html
void
On Tuesday, 15 June 2021 at 05:17:06 UTC, mw wrote:
I think there is another convention (although it's not formally
enforced, but should be) is:
-- `obj.front() [should be] const`, i.e. it shouldn't modify
`obj`, so can be called multiple times at any given state, and
produce the same result
On Tuesday, 15 June 2021 at 05:03:45 UTC, surlymoor wrote:
On Tuesday, 15 June 2021 at 04:57:45 UTC, mw wrote:
In English, `front` is a noun, `popFront` have a verb in it,
so you know who should do more work :-)
Sure, but, for example, the front method of Phobos' MapResult
is the one
On Tuesday, 15 June 2021 at 04:57:45 UTC, mw wrote:
In English, `front` is a noun, `popFront` have a verb in it, so
you know who should do more work :-)
Sure, but, for example, the front method of Phobos' MapResult is
the one applying the predicate to the source's front. There's a
clear
On Tuesday, 15 June 2021 at 04:24:09 UTC, surlymoor wrote:
All my custom range types perform all their meaningful work in
their respective popFront methods, in addition to its expected
source data iteration duties. The reason I do this is because I
swear I read in a github discussion that
On Tuesday, 15 June 2021 at 04:43:38 UTC, jfondren wrote:
Well, consider this program:
```d
import std;
struct Noisy {
int[] source;
int pops, fronts;
bool empty() { return source.empty; }
void popFront() { writeln("popFront #", ++pops);
source.popFront; }
int front() {
On Tuesday, 15 June 2021 at 04:24:09 UTC, surlymoor wrote:
All my custom range types perform all their meaningful work in
their respective popFront methods, in addition to its expected
source data iteration duties. The reason I do this is because I
swear I read in a github discussion that
All my custom range types perform all their meaningful work in
their respective popFront methods, in addition to its expected
source data iteration duties. The reason I do this is because I
swear I read in a github discussion that front is expected to be
O(1), and the only way I can think to
13 matches
Mail list logo
