Here's a minimal code example that duplicates the issue:
import std.array, std.range, std.stdio, std.traits, std.string;
auto readStream(Range)(auto ref Range r) if
(isInputRange!(Unqual!Range))
{
struct StreamRange(Range)
{
alias R = Unqual!Range;
On Wednesday, 29 April 2020 at 22:32:00 UTC, Simen Kjærås wrote:
I mean, it might be you messed up in posting this, but having
an empty popFront and expecting it to do something is a tad
optimistic.
I was just trying to get the example to a very minimal state. I
just added more descriptive c
On Thursday, 30 April 2020 at 13:04:47 UTC, Casey wrote:
Here's a minimal code example that duplicates the issue:
import std.array, std.range, std.stdio, std.traits, std.string;
auto readStream(Range)(auto ref Range r) if
(isInputRange!(Unqual!Range))
{
struct StreamRange(Range)
On Thursday, 30 April 2020 at 13:23:25 UTC, Paul Backus wrote:
On Thursday, 30 April 2020 at 13:04:47 UTC, Casey wrote:
Here's a minimal code example that duplicates the issue:
import std.array, std.range, std.stdio, std.traits, std.string;
auto readStream(Range)(auto ref Range r) if
(isInput
The recent change log for v2.092.0 Beta says that with the new
implementation for the `in` storage class:
`in` should be the storage class of choice for purely input
function parameters.
I had been using inout for some time now for "purely input
function parameters". Is there a case to be ma
On Thursday, 30 April 2020 at 14:00:40 UTC, Arredondo wrote:
I had been using inout for some time now for "purely input
function parameters".
`inout` is more specifically for things you take in, look at,
then pass back out. So it forms part of your return value.
`const` is for when you are j
On 4/30/20 10:52 AM, Adam D. Ruppe wrote:
On Thursday, 30 April 2020 at 14:00:40 UTC, Arredondo wrote:
I had been using inout for some time now for "purely input function
parameters".
`inout` is more specifically for things you take in, look at, then pass
back out. So it forms part of your re
On Thursday, 30 April 2020 at 13:23:25 UTC, Paul Backus wrote:
Using a default value like this means that it will be shared
among all instances of the struct. Instead, you should set
`buff = appender!string` in the constructor, so that each
struct will have its own appender.
I'll give it a tr
On Thursday, 30 April 2020 at 15:42:03 UTC, Casey wrote:
I'll give it a try when I get back to it (fixing lint issues),
but are you sure that's the issue? In popFront, I recreate the
appender. So, the appender should be clear before the empty
check after it processes the last of the data from
On 4/30/20 11:42 AM, Casey wrote:
On Thursday, 30 April 2020 at 13:23:25 UTC, Paul Backus wrote:
Using a default value like this means that it will be shared among all
instances of the struct. Instead, you should set `buff =
appender!string` in the constructor, so that each struct will have its
For ressource management I mostly use this pattern, to ensure the
destructor is run:
void myfunc(){
MyClass X = new MyClass(); scope(exit) X.destroy;
}
I somewhere read, this would work too:
void myfunc(){
auto MyClass X = new MyClass();
}
What does this "auto" does here? Wouldn't
void myf
On Thursday, 30 April 2020 at 16:55:36 UTC, Robert M. Münch wrote:
For ressource management I mostly use this pattern, to ensure
the destructor is run:
void myfunc(){
MyClass X = new MyClass(); scope(exit) X.destroy;
}
I somewhere read, this would work too:
void myfunc(){
auto MyClass X = n
On 4/30/20 12:55 PM, Robert M. Münch wrote:
For ressource management I mostly use this pattern, to ensure the
destructor is run:
void myfunc(){
MyClass X = new MyClass(); scope(exit) X.destroy;
}
I somewhere read, this would work too:
void myfunc(){
auto MyClass X = new MyClass();
}
What
On Thursday, 30 April 2020 at 16:21:05 UTC, Steven Schveighoffer
wrote:
I would say part of the issue is that you are doing all your
work in front and not popFront.
What happens is that Appender is a pointer-to-implementation
struct, and the compiler will allocate the first one shared
amongst
On Thursday, 30 April 2020 at 16:21:05 UTC, Steven Schveighoffer
wrote:
I would say part of the issue is that you are doing all your
work in front and not popFront.
[...]
I'd say:
1. move your work to the popFront function (you then need to
call popFront once before returning the range in
On 4/30/20 2:03 PM, Casey wrote:
Interesting. I'll take this into account. I was putting the work into
front because I didn't want to do the work until it was requested.
Putting the work in popFront makes more sense in some ways, but the fact
you have to call it before getting any records se
On Thu, Apr 30, 2020 at 06:05:55PM +, Paul Backus via Digitalmars-d-learn
wrote:
[...]
> Doing work in popFront instead of front is usually an anti-pattern,
> since it forces eager evaluation of the next element even when that
> element is never used. You should only do this if there's no
> re
On Thursday, 30 April 2020 at 18:30:14 UTC, H. S. Teoh wrote:
On Thu, Apr 30, 2020 at 06:05:55PM +, Paul Backus via
Digitalmars-d-learn wrote: [...]
Doing work in popFront instead of front is usually an
anti-pattern, since it forces eager evaluation of the next
element even when that elemen
On 4/30/20 2:05 PM, Paul Backus wrote:
On Thursday, 30 April 2020 at 16:21:05 UTC, Steven Schveighoffer wrote:
I would say part of the issue is that you are doing all your work in
front and not popFront.
[...]
I'd say:
1. move your work to the popFront function (you then need to call
popF
On 4/30/20 2:30 PM, H. S. Teoh wrote:
On Thu, Apr 30, 2020 at 06:05:55PM +, Paul Backus via Digitalmars-d-learn
wrote:
[...]
Doing work in popFront instead of front is usually an anti-pattern,
since it forces eager evaluation of the next element even when that
element is never used. You sho
On Thursday, 30 April 2020 at 18:30:14 UTC, H. S. Teoh wrote:
On Thu, Apr 30, 2020 at 06:05:55PM +, Paul Backus via
Digitalmars-d-learn wrote: [...]
Doing work in popFront instead of front is usually an
anti-pattern, since it forces eager evaluation of the next
element even when that elemen
On 4/30/20 6:39 PM, Paul Backus wrote:
On Thursday, 30 April 2020 at 18:30:14 UTC, H. S. Teoh wrote:
Also, for ranges based on generator functions, if .front is lazy then
you need to keep extra baggage around your range to indicate whether
or not the generator has been invoked yet; it's easier
22 matches
Mail list logo
