On 6/23/20 9:47 AM, Sebastiaan Koppe wrote:
On Tuesday, 23 June 2020 at 07:30:29 UTC, Stanislav Blinov wrote:
On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
I'm also wondering what's the motivation behind supporting
non-copyable ranges, and whether it's worth the effort and inevita
On Tuesday, 23 June 2020 at 03:52:23 UTC, Jonathan M Davis wrote:
It is extremely common to wrap ranges in other ranges (and in
fact, you basically have to in order to have lazy ranges). That
really doesn't work very well - if at all - if you can't copy
the range. It might be possible with a
On Tuesday, 23 June 2020 at 07:30:29 UTC, Stanislav Blinov wrote:
On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
I'm also wondering what's the motivation behind supporting
non-copyable ranges, and whether it's worth the effort and
inevitable complications to support it if it's a ra
On Tuesday, 23 June 2020 at 05:24:37 UTC, H. S. Teoh wrote:
On Tue, Jun 23, 2020 at 03:25:55AM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis
wrote:
> We'd need some major redesigning to make uncopyable ranges
> work, and person
On Tuesday, 23 June 2020 at 03:52:23 UTC, Jonathan M Davis wrote:
On Monday, June 22, 2020 9:25:55 PM MDT Stanislav Blinov via
Digitalmars-d- learn wrote:
On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis
wrote:
> As things stand, uncopyable ranges aren't really a thing,
> and common r
On Tue, Jun 23, 2020 at 03:25:55AM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
> On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis wrote:
>
> > As things stand, uncopyable ranges aren't really a thing, and common
> > range idiomns rely on ranges being copyable.
>
> Which idio
On Monday, June 22, 2020 9:25:55 PM MDT Stanislav Blinov via Digitalmars-d-
learn wrote:
> On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis wrote:
> > As things stand, uncopyable ranges aren't really a thing, and
> > common range idiomns rely on ranges being copyable.
>
> Which idioms are
On Tuesday, 23 June 2020 at 02:41:55 UTC, Jonathan M Davis wrote:
As things stand, uncopyable ranges aren't really a thing, and
common range idiomns rely on ranges being copyable.
Which idioms are those? I mean, genuine idioms, not design flaws
like e.g. references.
We'd need some major red
On Mon, Jun 22, 2020 at 08:53:22PM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote:
[...]
> Exactly. It's because of issues like this that generic, range-based
> functions need to be tested with a variety of range types - including
> reference types. Without that, bugs are routinely missed.
On Monday, June 22, 2020 3:33:08 PM MDT H. S. Teoh via Digitalmars-d-learn
wrote:
> On Mon, Jun 22, 2020 at 09:11:07PM +, Stanislav Blinov via Digitalmars-
d-learn wrote:
> > That is not true. Copying of forward ranges is absolutely fine. It's
> > what the current `save()` primitive is suppose
On Monday, June 22, 2020 3:11:07 PM MDT Stanislav Blinov via Digitalmars-d-
learn wrote:
> On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
> > You're unlikely to find much range-based code that does that
> > and there really isn't much point in doing that. Again, copying
> > isn't
On Monday, June 22, 2020 3:38:02 PM MDT Paul Backus via Digitalmars-d-learn
wrote:
> On Monday, 22 June 2020 at 21:33:08 UTC, H. S. Teoh wrote:
> > Jonathan is coming from the POV of generic code. The problem
> > with move leaving the original range in its .init state isn't
> > so much that it wi
On Monday, 22 June 2020 at 21:33:08 UTC, H. S. Teoh wrote:
Don't be shocked when you find out how many Phobos ranges have
.init states that are invalid (e.g., non-empty, but .front and
.popFront will crash / return invalid values).
Which ones?
Jonathan is coming from the POV of generic code.
On Monday, 22 June 2020 at 21:33:08 UTC, H. S. Teoh wrote:
Jonathan is coming from the POV of generic code. The problem
with move leaving the original range in its .init state isn't
so much that it will crash or anything (even though as you said
that does indicate a flaw in the range's imple
On Monday, June 22, 2020 3:10:28 PM MDT kinke via Digitalmars-d-learn wrote:
> On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
> > [...]
>
> That's why I put the struct in parantheses. Moving a class ref
> makes hardly any sense, but I've also never written a *class* to
> represent
On Mon, Jun 22, 2020 at 09:11:07PM +, Stanislav Blinov via
Digitalmars-d-learn wrote:
> On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
[...]
> > And moving doesn't fix anything, since the original variable is
> > still there (just in its init state, which would still be inval
On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
You're unlikely to find much range-based code that does that
and there really isn't much point in doing that. Again, copying
isn't the problem. It's using the original after making the
copy that's the problem.
Copy *is* the pro
On Monday, 22 June 2020 at 20:51:37 UTC, Jonathan M Davis wrote:
[...]
That's why I put the struct in parantheses. Moving a class ref
makes hardly any sense, but I've also never written a *class* to
represent a range. Moving is the no-brainer solution for
transferring ownership of struct ran
On Monday, June 22, 2020 1:41:34 PM MDT kinke via Digitalmars-d-learn wrote:
> On Monday, 22 June 2020 at 19:03:44 UTC, Jonathan M Davis wrote:
> > in practice, that means that generic code cannot use a range
> > once it's been copied
>
> Translating to a simple rule-of-thumb: never copy a (struct)
On Monday, 22 June 2020 at 19:03:44 UTC, Jonathan M Davis wrote:
in practice, that means that generic code cannot use a range
once it's been copied
Translating to a simple rule-of-thumb: never copy a (struct)
range, always move.
On Monday, June 22, 2020 10:59:45 AM MDT kinke via Digitalmars-d-learn wrote:
> If copying a range is considered to be generally unsafe and a
> common pitfall (vs. the save() abomination), maybe range-foreach
> shouldn't allow any lvalue ranges in the 1st place, thus not
> making any copies and for
On Monday, 22 June 2020 at 16:25:11 UTC, Jonathan M Davis wrote:
The reason that foreach copies the range is simply due to how
the code is lowered. e.g.
foreach(e; range)
{
}
essentially becomes
for(auto r = range; !r.empty; r.popFront())
{
auto e = r.front;
}
On Sunday, June 21, 2020 2:25:37 PM MDT kinke via Digitalmars-d-learn wrote:
> A foreach over a custom range makes an initial copy, so that the
> original range is still usable after the foreach (not empty).
No, it's not so that the range will be useable afterwards. In fact, for
generic code, you
A foreach over a custom range makes an initial copy, so that the
original range is still usable after the foreach (not empty).
https://pastebin.com/BYcRN8T2
why called copy constructor for ref Range struct type in foreach ?
```
struct MyRange {
private int current_row = 0;
private int rows_count = 5;
@disable this(this); // <===
bool empty () { return current_row == rows_count; }
int front() { return
25 matches
Mail list logo
