On Wednesday, 25 August 2021 at 11:02:23 UTC, Steven
Schveighoffer wrote:
On 8/25/21 4:31 AM, frame wrote:
On Tuesday, 24 August 2021 at 21:15:02 UTC, Steven
Schveighoffer wrote:
I'm surprised you bring PHP as an example, as it appears
their foreach interface works EXACTLY as D does:
Yeah, bu
On Wednesday, 25 August 2021 at 19:51:36 UTC, H. S. Teoh wrote:
What I understand from what Andrei has said in the past, is
that a range is merely a "view" into some underlying storage;
it is not responsible for the contents of that storage. My
interpretation of this is that .save will only sa
On Wed, Aug 25, 2021 at 04:46:54PM +, Joseph Rushton Wakeling via
Digitalmars-d-learn wrote:
> On Wednesday, 25 August 2021 at 10:59:44 UTC, Steven Schveighoffer wrote:
> > structs still provide a mechanism (postblit/copy ctor) to properly
> > save a forward range when copying, even if the gut
On Wednesday, 25 August 2021 at 17:01:54 UTC, Steven
Schveighoffer wrote:
In a world where copyability means it's a forward range? Yes.
We aren't in that world, it's a hypothetical "if we could go
back and redesign".
OK, that makes sense.
Technically this is true. In practice, it rarely happe
On 8/25/21 12:46 PM, Joseph Rushton Wakeling wrote:
On Wednesday, 25 August 2021 at 10:59:44 UTC, Steven Schveighoffer wrote:
structs still provide a mechanism (postblit/copy ctor) to properly
save a forward range when copying, even if the guts need copying
(unlike classes). In general, I think
On Wednesday, 25 August 2021 at 10:59:44 UTC, Steven
Schveighoffer wrote:
structs still provide a mechanism (postblit/copy ctor) to
properly save a forward range when copying, even if the guts
need copying (unlike classes). In general, I think it was a
mistake to use `.save` as the mechanism, a
On 8/25/21 7:26 AM, Alexandru Ermicioi wrote:
On Wednesday, 25 August 2021 at 11:04:35 UTC, Steven Schveighoffer wrote:
It never has called `save`. It makes a copy, which is almost always
the equivalent `save` implementation.
Really?
Then what is the use for .save method then?
The only reas
On Wednesday, 25 August 2021 at 11:04:35 UTC, Steven
Schveighoffer wrote:
It never has called `save`. It makes a copy, which is almost
always the equivalent `save` implementation.
-Steve
Really?
Then what is the use for .save method then?
The only reason I can find is that you can't declare
On 8/25/21 6:06 AM, Alexandru Ermicioi wrote:
On Wednesday, 25 August 2021 at 08:15:18 UTC, frame wrote:
I know, but foreach() doesn't call save().
Hmm, this is a regression probably, or I missed the time frame when
foreach moved to use of copy constructor for forward ranges.
Do we have a w
On 8/25/21 4:31 AM, frame wrote:
On Tuesday, 24 August 2021 at 21:15:02 UTC, Steven Schveighoffer wrote:
I'm surprised you bring PHP as an example, as it appears their foreach
interface works EXACTLY as D does:
Yeah, but the point is, there is a rewind() method. That is called every
time on f
On 8/25/21 6:06 AM, Joseph Rushton Wakeling wrote:
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied when
the foreach loop is created.
That's quite a strong assumption, because its state might be a reference
type, or it mig
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied
when the foreach loop is created.
That's quite a strong assumption, because its state might be a
reference type, or it might not _have_ state in a meaningful
sense -- consid
On Wednesday, 25 August 2021 at 08:15:18 UTC, frame wrote:
I know, but foreach() doesn't call save().
Hmm, this is a regression probably, or I missed the time frame
when foreach moved to use of copy constructor for forward ranges.
Do we have a well defined description of what input, forward
On Wednesday, 25 August 2021 at 06:51:36 UTC, bauss wrote:
Of course it doesn't disallow classes but it's generally
advised that you use structs and that's what you want in 99% of
the cases. It's usually a red flag when a range starts being a
reference type.
Well, sometimes you can't avoid re
On Tuesday, 24 August 2021 at 21:15:02 UTC, Steven Schveighoffer
wrote:
If you have a for loop:
```d
int i;
for(i = 0; i < someArr.length; ++i)
{
if(someArr[i] == desiredValue) break;
}
```
You are saying, "compiler, please execute the `++i` when I
break from the loop because I already pr
On Tuesday, 24 August 2021 at 18:52:19 UTC, Alexandru Ermicioi
wrote:
Forward range exposes also capability to create save points,
which is actually used by foreach to do, what it is done in
java by iterable interface for example.
I know, but foreach() doesn't call save().
On Tuesday, 24 August 2021 at 19:06:44 UTC, Alexandru Ermicioi
wrote:
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied
when the foreach loop is created.
Actually the range contracts don't mention that it needs to be
a by
On 8/24/21 1:44 PM, Ferhat Kurtulmuş wrote:
> Just out of curiosity, if a range implementation uses malloc in save, is
> it only possible to free the memory with the dtor?
Yes but It depends on the specific case. For example, if the type has a
clear() function that does clean up, then one might
On 8/24/21 2:12 PM, frame wrote:
You can call `popFront` if you need to after the loop, or just before
the break. I have to say, the term "useless" does not even come close
to describing ranges using foreach in my experience.
I disagree, because foreach() is a language construct and therefore
On Tuesday, 24 August 2021 at 19:06:44 UTC, Alexandru Ermicioi
wrote:
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
[...]
Actually the range contracts don't mention that it needs to be
a by value type. It can also be a reference type, i.e. a class.
[...]
True for any forward r
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied
when the foreach loop is created.
Actually the range contracts don't mention that it needs to be a
by value type. It can also be a reference type, i.e. a class.
Which m
On Tuesday, 24 August 2021 at 08:36:18 UTC, frame wrote:
How do you handle that issue? Are your ranges designed to have
this bug or do you implement opApply() always?
This is expected behavior imho. I think what you need is a
forward range, not input range. By the contract of input range,
it
On Tuesday, 24 August 2021 at 16:45:27 UTC, H. S. Teoh wrote:
In some cases, you *want* to retain the same element between
loops, e.g., if you're iterating over elements of some category
and stop when you encounter something that belongs to the next
category -- you wouldn't want to consume t
On Tuesday, 24 August 2021 at 13:02:38 UTC, Steven Schveighoffer
wrote:
On 8/24/21 4:36 AM, frame wrote:
Consider a simple input range that can be iterated with
empty(), front() and popFront(). That is comfortable to use
with foreach() but what if the foreach loop will be cancelled?
If a range
On Tue, Aug 24, 2021 at 08:36:18AM +, frame via Digitalmars-d-learn wrote:
> Consider a simple input range that can be iterated with empty(),
> front() and popFront(). That is comfortable to use with foreach() but
> what if the foreach loop will be cancelled? If a range isn't depleted
> yet and
On 8/24/21 4:36 AM, frame wrote:
Consider a simple input range that can be iterated with empty(), front()
and popFront(). That is comfortable to use with foreach() but what if
the foreach loop will be cancelled? If a range isn't depleted yet and
continued it will supply the same data twice on f
On Tuesday, 24 August 2021 at 09:26:20 UTC, jfondren wrote:
I think you strayed from the beaten path, in a second way, as
soon as your range's lifetime escaped a single expression, to
be possibly used in two foreach loops. With ranges, as you do
more unusual things, you're already encouraged t
On Tuesday, 24 August 2021 at 09:15:23 UTC, bauss wrote:
A range should be a struct always and thus its state is copied
when the foreach loop is created.
This is not conform with the aggregate expression mentioned in
the manual where a class object would be also allowed.
Which means the
On Tuesday, 24 August 2021 at 08:36:18 UTC, frame wrote:
Consider a simple input range that can be iterated with
empty(), front() and popFront(). That is comfortable to use
with foreach() but what if the foreach loop will be cancelled?
If a range isn't depleted yet and continued it will supply
On Tuesday, 24 August 2021 at 08:36:18 UTC, frame wrote:
Consider a simple input range that can be iterated with
empty(), front() and popFront(). That is comfortable to use
with foreach() but what if the foreach loop will be cancelled?
If a range isn't depleted yet and continued it will supply
Consider a simple input range that can be iterated with empty(),
front() and popFront(). That is comfortable to use with foreach()
but what if the foreach loop will be cancelled? If a range isn't
depleted yet and continued it will supply the same data twice on
front() in the next use of foreach
31 matches
Mail list logo