On Wednesday, 24 April 2024 at 05:08:25 UTC, Salih Dincer wrote:
Yes, `opApply()` works! You just need to use `do while()`
instead of `while()` because it skips the first item.
It depends on the type of structure being consumed, if it
provides "next" as a direct pointer then yeah you would
On Tuesday, 23 April 2024 at 06:02:18 UTC, cc wrote:
Just to offer an alternative solution (since it sometimes gets
overlooked), there is also the `opApply` approach. You don't
get full forward range status, and checking whether it's empty
essentially requires doing something like
On Monday, 22 April 2024 at 11:36:43 UTC, Chloé wrote:
I wish to adapt this interface to a forward range for use with
foreach and Phobos' range utilities. This amounts to
implementing empty, front, and popFront, in terms of next and
some state. But there is a choice to be made regarding the
On Monday, 22 April 2024 at 11:36:43 UTC, Chloé wrote:
The first implementation has the advantage is being simpler and
empty being const, but has the downside that next is called
even if the range ends up not being used. Is either approach
used consistently across the D ecosystem?
I always
also place initialization logic inside front, then empty
could become const.
I don't think there is a preffered way of initializing such
ranges, so imho consider what's best for your use case.
Assume a third-party API of the following signature:
T* next(I iter);
which advances an iterator of sorts and returns the next element, or
null when iteration is done. No other information about the state of the
iterator is available.
I wish to adapt this interface to a forward range
On Tuesday, 3 October 2023 at 20:22:30 UTC, Andrey Zherikov wrote:
On Tuesday, 3 October 2023 at 19:57:06 UTC, christian.koestlin
wrote:
On Tuesday, 3 October 2023 at 01:55:43 UTC, Andrey Zherikov
wrote:
On Monday, 2 October 2023 at 18:46:14 UTC, christian.koestlin
wrote:
[...]
Slightly
On Tuesday, 3 October 2023 at 19:57:06 UTC, christian.koestlin
wrote:
On Tuesday, 3 October 2023 at 01:55:43 UTC, Andrey Zherikov
wrote:
On Monday, 2 October 2023 at 18:46:14 UTC, christian.koestlin
wrote:
[...]
Slightly improved:
```d
import std;
[...]
Thanks .. the thing with ref result
On Tuesday, 3 October 2023 at 01:55:43 UTC, Andrey Zherikov wrote:
On Monday, 2 October 2023 at 18:46:14 UTC, christian.koestlin
wrote:
[...]
Slightly improved:
```d
import std;
[...]
Thanks .. the thing with ref result is very clever!
Should `ref result` be `return result`?
Kind regards,
On Monday, 2 October 2023 at 02:47:37 UTC, Joel wrote:
```d
import std;
auto data=“I went for a walk, and fell down a hole.”;
```
[snip]
How can I improve this code? Like avoiding using foreach.
This works for me:
```d
import std;
auto data="I went for a walk, and fell down a hole.";
On Monday, 2 October 2023 at 18:46:14 UTC, christian.koestlin
wrote:
On Monday, 2 October 2023 at 02:47:37 UTC, Joel wrote:
How can I improve this code? Like avoiding using foreach.
You could fold into a hash that counts the occurrences like
that:
```d
import std.uni : toLower;
import
On Monday, 2 October 2023 at 20:20:44 UTC, Joel wrote:
I want the output sorted by value.
Look:
https://forum.dlang.org/post/qjlmiohaoeolmoavw...@forum.dlang.org
```d
struct SIRALA(T) { }
```
You can use SIRALA(T). Okay, his language is Turkish but our
common language is D. His feature
On Monday, 2 October 2023 at 02:47:37 UTC, Joel wrote:
```d
import std;
auto data=“I went for a walk, and fell down a hole.”;
void main(string[] args) {
int[string] dic;
struct WordCnt {
string word;
ulong count;
string toString() const {
return
On Monday, 2 October 2023 at 06:19:29 UTC, Imperatorn wrote:
On Monday, 2 October 2023 at 02:47:37 UTC, Joel wrote:
```d
import std;
auto data=“I went for a walk, and fell down a hole.”;
You can improve it further by inlining
```d
import std;
auto data = "I went for a walk, and fell down a
On Monday, 2 October 2023 at 02:47:37 UTC, Joel wrote:
How can I improve this code? Like avoiding using foreach.
You could fold into a hash that counts the occurrences like that:
```d
import std.uni : toLower;
import std.array : split, array;
import std.stdio : writeln;
import std.algorithm :
On Monday, 2 October 2023 at 02:47:37 UTC, Joel wrote:
```d
import std;
auto data=“I went for a walk, and fell down a hole.”;
You can improve it further by inlining
```d
import std;
auto data = "I went for a walk, and fell down a hole.";
void main(string[] args)
{
int[string] dic;
On Monday, 2 October 2023 at 02:47:37 UTC, Joel wrote:
```d
import std;
auto data=“I went for a walk, and fell down a hole.”;
void main(string[] args) {
int[string] dic;
struct WordCnt {
string word;
ulong count;
string toString() const {
return
```d
import std;
auto data=“I went for a walk, and fell down a hole.”;
void main(string[] args) {
int[string] dic;
struct WordCnt {
string word;
ulong count;
string toString() const {
return text("Word: ", word, " - number of instances:
", count);
On Sunday, 7 August 2022 at 21:57:50 UTC, Ali Çehreli wrote:
On 8/7/22 08:34, pascal111 wrote:
> but after that in advanced level in programming, we should
> use pointers to do same tasks we were doing with slices (the
easy way of
> beginners).
That is an old thought. Today, we see that no
On 8/6/22 22:58, Salih Dincer wrote:
> Ranges are not like that, all they do is
> generate.
You may be right. I've never seen it that way.
I've been under the following impression:
- C++'s iterators are based on an existing concept: pointers. Pointers
are iterators.
- D's ranges are
On 8/7/22 08:34, pascal111 wrote:
> Everyone knows that slices are not pointers
D's slices are "fat pointers": In D's case, that translates to a pointer
plus length.
> that pointers are real work,
Agreed. Pointers are fundamental features of CPUs.
> but slices are like a simple un-deep
On Sunday, 7 August 2022 at 19:53:06 UTC, ag0aep6g wrote:
On Sunday, 7 August 2022 at 15:34:19 UTC, pascal111 wrote:
Everyone knows that slices are not pointers that pointers are
real work, but slices are like a simple un-deep technique that
is appropriate for beginners, but after that in
here.
Ranges and Slices are not the same thing. Slicing an array is
easy. This is a language possibility. For example, you need an
incrementing variable for the Fibonacci Series.
SDB@79
What!!! so where's ranges?! I thought slices of any array are
ranges, and understood it like
On Sunday, 7 August 2022 at 15:34:19 UTC, pascal111 wrote:
Everyone knows that slices are not pointers that pointers are
real work, but slices are like a simple un-deep technique that
is appropriate for beginners, but after that in advanced level
in programming, we should use pointers to do
On Sunday, 7 August 2022 at 15:34:19 UTC, pascal111 wrote:
Everyone knows that slices are not pointers that pointers are
real work, but slices are like a simple un-deep technique that
is appropriate for beginners, but after that in advanced level
in programming, we should use pointers to do
On Sunday, 7 August 2022 at 05:12:38 UTC, Ali Çehreli wrote:
On 8/6/22 14:10, pascal111 wrote:
> a powerful point in the account of C.
I missed how you made that connection.
Everyone knows that slices are not pointers that pointers are
real work, but slices are like a simple un-deep
On Saturday, 6 August 2022 at 17:29:30 UTC, Ali Çehreli wrote:
On 8/6/22 09:33, Salih Dincer wrote:
> the slices feel like ranges, don't they?
Yes because they are ranges. :) (Maybe you meant they don't
have range member functions, which is true.)
Slices use pointers. Do I need to tell
On 8/6/22 14:10, pascal111 wrote:
> the problem is that ranges in D lack the usage of pointers as
> an essential tool to make all of ranges functions they need. If ranges
> exist in C, they would use pointers, and this is
There are a few cases where pointers provide functionality th
On Saturday, 6 August 2022 at 15:54:57 UTC, H. S. Teoh wrote:
On Sat, Aug 06, 2022 at 03:37:32PM +, pascal111 via
Digitalmars-d-learn wrote:
On Friday, 5 August 2022 at 04:05:08 UTC, Salih Dincer wrote:
> On Thursday, 4 August 2022 at 22:54:42 UTC, pascal111 wrote:
> > [...]
&g
On 8/6/22 09:33, Salih Dincer wrote:
> the slices feel like ranges, don't they?
Yes because they are ranges. :) (Maybe you meant they don't have range
member functions, which is true.)
D's slices happen to be the most capable range kind: RandonAccessRange.
All of the following operati
On Saturday, 6 August 2022 at 16:30:55 UTC, Salih Dincer wrote:
Indeed, the slices (we can call it a dynamic array) feel like
slice, don't they?
Edit: Indeed, the slices feel like ranges, don't they?
Sorry...
SDB@79
here.
Ranges and Slices are not the same thing. Slicing an array is
easy. This is a language possibility. For example, you need an
incrementing variable for the Fibonacci Series.
SDB@79
What!!! so where's ranges?! I thought slices of any array are
ranges, and understood it like
eeds to pop a range forward is
> > > just a slice, yes, we don't need variable here.
> >
> > Ranges and Slices are not the same thing. Slicing an array is easy.
> > This is a language possibility. For example, you need an
> > incrementing variable for the Fibonacci Series
On Friday, 5 August 2022 at 04:05:08 UTC, Salih Dincer wrote:
On Thursday, 4 August 2022 at 22:54:42 UTC, pascal111 wrote:
I didn't notice that all what we needs to pop a range forward
is just a slice, yes, we don't need variable here.
Ranges and Slices are not the same thing. Slicing
could be
aliased by another slice, for example, so you can't just tell by whether
you're copying an overlapping range from the same variable).
But if you know beforehand the ranges being copied are overlapping, you
could use std.algorithm.bringToFront which would do the Right Thing(tm)
in this ca
On 8/5/22 01:59, frame wrote:
> On Thursday, 4 August 2022 at 22:14:26 UTC, Ali Çehreli wrote:
>
>> No element is copied or moved. :)
>>
>> Ali
>
> I know that :)
And I know that. :) We don't know who else is reading these threads, so
I didn't want to give wrong impression.
Copying would
On Thursday, 4 August 2022 at 22:14:26 UTC, Ali Çehreli wrote:
No element is copied or moved. :)
Ali
I know that :) I just found that this user has problems to
understand basics in D, so I tried not to go in detail and keep
at its kind of logical layer. It seems the better way to help
On Thursday, 4 August 2022 at 22:54:42 UTC, pascal111 wrote:
I didn't notice that all what we needs to pop a range forward
is just a slice, yes, we don't need variable here.
Ranges and Slices are not the same thing. Slicing an array is
easy. This is a language possibility. For example, you
On Thursday, 4 August 2022 at 22:14:26 UTC, Ali Çehreli wrote:
On 8/4/22 11:05, frame wrote:
> `popFront()`
The function was this:
void popFront() {
students = students[1 .. $];
}
> copies all
> elements except the first one into the variable (and
overwrites it), so
>
On 8/4/22 11:05, frame wrote:
> `popFront()`
The function was this:
void popFront() {
students = students[1 .. $];
}
> copies all
> elements except the first one into the variable (and overwrites it), so
> it moves the data forward.
That would be very slow. :) What
ds to program "empty()", "front()", and
> "popFront()" functions for ranges
The programmer almost never needs to implement those functions. Existing
data structures and algorithms are almost always sufficient. (I did need
to implement them but really rarely.)
I t
On Thursday, 4 August 2022 at 13:08:21 UTC, pascal111 wrote:
1) Why the programmer needs to program "empty()", "front()",
and "popFront()" functions for ranges while they exist in the
language library? it seems there's no need to exert efforts for
t
On Thursday, 4 August 2022 at 13:08:21 UTC, pascal111 wrote:
```D
import std.stdio;
import std.string;
struct Student {
string name;
int number;
string toString() const {
return format("%s(%s)", name, number);
}
}
struct School {
In next code from
"https://www.tutorialspoint.com/d_programming/d_programming_ranges.htm;, we have two issues:
1) Why the programmer needs to program "empty()", "front()", and
"popFront()" functions for ranges while they exist in the
language library? it see
On Saturday, 16 July 2022 at 12:40:09 UTC, Paul Backus wrote:
On Saturday, 16 July 2022 at 08:40:10 UTC, D Lark wrote:
On Wednesday, 13 July 2022 at 01:40:43 UTC, Paul Backus wrote:
On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote:
[...]
Yes, it should behave the way you expect. The
On Saturday, 16 July 2022 at 08:40:10 UTC, D Lark wrote:
On Wednesday, 13 July 2022 at 01:40:43 UTC, Paul Backus wrote:
On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote:
First, please can someone clarify if the behaviour I expect
in the last line is consistent with the intention of the
. We can even have a mixin like
the `ImplementLength` one that can add both `infinite` and
`empty` in one go, which might be useful for implementing
infinite ranges.
On Wednesday, 13 July 2022 at 01:40:43 UTC, Paul Backus wrote:
On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote:
First, please can someone clarify if the behaviour I expect in
the last line is consistent with the intention of the library?
Yes, it should behave the way you expect. The
On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote:
First, please can someone clarify if the behaviour I expect in
the last line is consistent with the intention of the library?
Yes, it should behave the way you expect. The current behavior is
a bug.
I've submitted a report for it
ect interface.
However it seems that the implementation of `InputRangeObject`
does not implement `enum bool empty = false` in the case of the
`RandomAccessInfinite` ranges, which leads to the template
`isRandomAccessRange` returning false.
On Monday, 13 June 2022 at 14:03:13 UTC, Steven Schveighoffer
wrote:
Merge sort only works if it's easy to manipulate the structure,
like a linked-list, or to build a new structure, like if you
don't care about allocating a new array every iteration.
The easiest option is to have two buffers
On 6/13/22 9:44 AM, Ola Fosheim Grøstad wrote:
On Monday, 13 June 2022 at 13:22:52 UTC, Steven Schveighoffer wrote:
I would think sort(joiner([arr1, arr2, arr3])) should work, but it's
not a random access range.
Yes, I got the error «must satisfy the following constraint:
On Monday, 13 June 2022 at 13:22:52 UTC, Steven Schveighoffer
wrote:
I would think sort(joiner([arr1, arr2, arr3])) should work, but
it's not a random access range.
Yes, I got the error «must satisfy the following constraint:
isRandomAccessRange!Range`».
It would be relatively easy to make
= [6, 8, 3];
sort(chain(arr1, arr2, arr3));
writefln("%s\n%s\n%s\n", arr1, arr2, arr3);
}
```
But it would be much more useful in practice if "chain" was a dynamic
array.
`chain` allows ranges of different types.
`joiner` should be the equivalent for a dyn
don't use ranges, but I thought this specific use case could be
valuable.
Imagine you have a chunked datastructure of unknown lengths, and
you want to "redistribute" items without reallocation.
On Monday, 13 June 2022 at 08:51:03 UTC, Ola Fosheim Grøstad
wrote:
But it would be much more useful in practice if "chain" was a
dynamic array.
Already so:
```d
int[] arr = [4, 9, 7, 5, 2, 1, 10, 6, 8, 3];
int[] arr1 = arr[0..3];
int[] arr2 = arr[3..7];
int[] arr3 = arr[7..$];
Is there a dynamic chain primitive, so that you can add to the
chain at runtime?
Context: the following example on the front page is interesting.
```d
void main()
{
int[] arr1 = [4, 9, 7];
int[] arr2 = [5, 2, 1, 10];
int[] arr3 = [6, 8, 3];
sort(chain(arr1, arr2, arr3));
> On Friday, 21 January 2022 at 17:25:20 UTC, Ali Çehreli wrote:
[...]
> > Additionally, just because we *provide* a step, now we *require*
> > division from all types (making it very cumbersome for user-defined
> > types).
[...]
It doesn't have to be this way. We could just use DbI to inspect
On Friday, 21 January 2022 at 17:25:20 UTC, Ali Çehreli wrote:
Ouch! I tried the following code, my laptop got very hot, it's
been centuries, and it's still running! :p
:)
```d
size_t length() inout {
auto len = 1 + (last - first) / step;
return cast(size_t)len;
}
```
Does
On 1/21/22 08:58, Salih Dincer wrote:
> ```d
> auto inclusiveRange(T)(T f, T l, T s = cast(T)0)
> in(!isBoolean!T) {
'in' contracts are checked at runtime. The one above does not make sense
because you already disallow compilation for 'bool' below.
You could add a template constraint there:
On Thursday, 20 January 2022 at 16:33:20 UTC, Ali Çehreli wrote:
So if we add the 1.0 value after 0.900357627869 to be
*inclusive*, then that last step would not be 0.3 anymore.
(Thinking about it, step would mess up things for integral
types as well; so, it must be checked during
.g. MyDiffType.
Having said that, floating point types don't make sense with the
semantics of a *bidirectional and inclusive* range. :) Let's see how it
looks for ranges where the step size is 0.3:
import std.stdio;
void main() {
float beg = 0.0;
float end = 1.0;
float step = 0.3;
Hi,
It looks so delicious. Thank you.
On Wednesday, 19 January 2022 at 18:59:10 UTC, Ali Çehreli wrote:
And adding length() was easy as well.
Finally, I have provided property functions instead of allowing
direct access to members.
It doesn't matter as we can't use a 3rd parameter. But
rimenting with that as well. The implementation below
does not care if popFront() or popBack() are called on empty ranges. The
programmer must be careful. :)
> "Does it reverse the result
> in case ```a > b``` like we
> did with foreach_reverse()"
No, it should not reverse th
On Tuesday, 18 January 2022 at 23:13:14 UTC, Ali Çehreli wrote:
But I like the following one better because
it is fast and I think it works correctly.
Is it okay to swap places instead of throwing an error? Let's
also implement BidirectionalRange, if okay. This great struct
will now run 4x4
number ranges 'directly', and
instead use a wrapper function...
auto range(T:T)(T a, T b)
{
import std.range : iota;
return iota(a, (b+1));
}
Aww, come on; it ain't that bad...
Well that depends on entirely on what the code is doing ;-)
The key is to *always* *remember* the stop index
On Tuesday, 18 January 2022 at 20:43:08 UTC, forkit wrote:
On Tuesday, 18 January 2022 at 16:02:42 UTC, Tejas wrote:
Newer languages nowadays use `start..intent, think it's something we should follow?
I've decided to avoid using number ranges 'directly', and
instead use a wrapper function
On Tuesday, 18 January 2022 at 17:58:54 UTC, H. S. Teoh wrote:
On Tue, Jan 18, 2022 at 04:02:42PM +, Tejas via
Digitalmars-d-learn wrote: [...]
Newer languages nowadays use `start..intent, think it's something we should follow?
I've never seen that before. Which languages use that?
T
On Monday, 17 January 2022 at 22:28:10 UTC, H. S. Teoh wrote:
This will immediately make whoever reads the code (i.e., myself
after 2 months :D) wonder, "why +1?" And the answer will become
clear and enlightenment ensues. ;-)
In those cases i find myself rewriting said code. Generally to
On 1/18/22 14:08, forkit wrote:
> never use number ranges.. not ever! ;-)
>
> (except in combination with iota)
Indeed, the following is an elegant but slow (tested with dmd)
implementation with Phobos:
auto range(T)(T a, T b)
in (a <= b) {
import std.range : chain, iota, on
', the range
will produce ints.
Ali
a change of mind...
never use number ranges.. not ever! ;-)
(except in combination with iota)
On 1/18/22 12:43, forkit wrote:
> wrapper function...
>
>
> auto range(T:T)(T a, T b)
> {
> import std.range : iota;
> return iota(a, (b+1));
> }
Needs a little more work to be correct. The following produces and empty
range. ;)
range(uint.min, uint.max)
Also, is it important
On Tuesday, 18 January 2022 at 16:02:42 UTC, Tejas wrote:
Newer languages nowadays use `start..intent, think it's something we should follow?
I've decided to avoid using number ranges 'directly', and instead
use a wrapper function...
auto range(T:T)(T a, T b)
{
import std.range : iota
On Tue, Jan 18, 2022 at 04:02:42PM +, Tejas via Digitalmars-d-learn wrote:
[...]
> Newer languages nowadays use `start.. it's something we should follow?
I've never seen that before. Which languages use that?
T
--
"If you're arguing, you're losing." -- Mike Thomas
On Monday, 17 January 2022 at 22:48:17 UTC, H. S. Teoh wrote:
On Mon, Jan 17, 2022 at 10:35:30PM +, forkit via
Digitalmars-d-learn wrote:
On Monday, 17 January 2022 at 22:28:10 UTC, H. S. Teoh wrote:
> [...]
[...]
If I were able to write a compiler, my compiler would warn you:
"This is
On Mon, Jan 17, 2022 at 10:35:30PM +, forkit via Digitalmars-d-learn wrote:
> On Monday, 17 January 2022 at 22:28:10 UTC, H. S. Teoh wrote:
> >
> > If I ever needed to foreach over 1-based indices, I'd write it this
> > way in order to avoid all confusion:
> >
> > foreach (i; 1 .. 5 + 1)
On Monday, 17 January 2022 at 22:28:10 UTC, H. S. Teoh wrote:
If I ever needed to foreach over 1-based indices, I'd write it
this way in order to avoid all confusion:
foreach (i; 1 .. 5 + 1)
{
}
This will immediately make whoever reads the code (i.e., myself
after 2
On Mon, Jan 17, 2022 at 10:22:19PM +, forkit via Digitalmars-d-learn wrote:
[...]
> I think it's fair to say, that I'm familiar with 0-based indexing ;-)
>
> my concern was with the 1..5 itself.
>
> In terms of what makes sense, it actually makes more sense not to use
> it, at all ;-)
If I
On Monday, 17 January 2022 at 22:06:47 UTC, H. S. Teoh wrote:
Basically,
foreach (i; a .. b)
is equivalent to:
for (auto i = a; i < b; i++)
Just think of that way and it will make sense.
I think it's fair to say, that I'm familiar with 0-based indexing
;-)
my concern
On Mon, Jan 17, 2022 at 09:37:31PM +, forkit via Digitalmars-d-learn wrote:
> On Monday, 17 January 2022 at 11:58:18 UTC, Paul Backus wrote:
> >
> > This kind of half-open interval, which includes the lower bound but
> > excludes the upper bound, is used in programming because it lets you
> >
On Monday, 17 January 2022 at 11:58:18 UTC, Paul Backus wrote:
This kind of half-open interval, which includes the lower bound
but excludes the upper bound, is used in programming because it
lets you write
foreach (i; 0 .. array.length) writef("%s ", array[i]);
...without going past
On Monday, 17 January 2022 at 11:58:18 UTC, Paul Backus wrote:
On Monday, 17 January 2022 at 10:24:06 UTC, forkit wrote:
Edsger W. Dijkstra, a well-known academic computer scientist,
has written in more detail about the advantages of this kind of
interval:
On Monday, 17 January 2022 at 10:24:06 UTC, forkit wrote:
so I'm wondering why the code below prints:
1 2 3 4
and not
1 2 3 4 5
as I would expect.
foreach (value; 1..5) writef("%s ", value);
This kind of half-open interval, which includes the lower bound
but excludes the upper bound, is
so I'm wondering why the code below prints:
1 2 3 4
and not
1 2 3 4 5
as I would expect.
foreach (value; 1..5) writef("%s ", value);
also, why is this not possible:
int[] arr = 1..5.array;
On 11/26/21 5:44 AM, Salih Dincer wrote:
Hi All;
I have two questions that make each other redundant. Please answer one
of them. I'm implementing ```bool empty() const``` for ranges as below:
```d
bool empty() // const
{
bool result;
if(!head)
{
result = true
On Friday, 26 November 2021 at 10:44:10 UTC, Salih Dincer wrote:
* Is the const essential for ranges?
* Is it possible to rewind the pointer (```Node * head;```)
when my head is empty by the const?
`empty` is not required to be `const`, but it is required to
yield the same result if called
Hi All;
I have two questions that make each other redundant. Please
answer one of them. I'm implementing ```bool empty() const``` for
ranges as below:
```d
bool empty() // const
{
bool result;
if(!head)
{
result = true;
fastRewind();
}
return result
ks exactly how I wanted. Thanks!
Be careful with this! `not!empty` is *only* working because you are
using arrays (where `empty` is a UFCS function defined in std.range).
Other ranges this will not work on. Instead, I would recommend a lambda
(which will work with arrays too):
```d
.filter!(r => !r.empty)
```
-Steve
On Friday, 27 August 2021 at 04:01:19 UTC, Ali Çehreli wrote:
On 8/26/21 7:17 PM, Merlin Diavova wrote:
[...]
Then the operations downstream will not produce any results.
For example, the array will be empty below:
import std.stdio;
import std.range;
import std.algorithm;
import
On 8/26/21 7:17 PM, Merlin Diavova wrote:
What I meant about the handling an empty filter is, what if I want to
take an alternative route if the filter returns empty?
Then the operations downstream will not produce any results. For
example, the array will be empty below:
import std.stdio;
On Friday, 27 August 2021 at 02:17:21 UTC, Merlin Diavova wrote:
On Friday, 27 August 2021 at 02:10:48 UTC, Stefan Koch wrote:
On Friday, 27 August 2021 at 01:51:42 UTC, Merlin Diavova
wrote:
Hi all,
I'm Merlin, I'm just starting out in D and super excited.
My questions are:-
1. In a range
On Friday, 27 August 2021 at 02:10:48 UTC, Stefan Koch wrote:
On Friday, 27 August 2021 at 01:51:42 UTC, Merlin Diavova wrote:
Hi all,
I'm Merlin, I'm just starting out in D and super excited.
My questions are:-
1. In a range pipeline how does one handle the event of a
filter range
On Friday, 27 August 2021 at 01:51:42 UTC, Merlin Diavova wrote:
Hi all,
I'm Merlin, I'm just starting out in D and super excited.
My questions are:-
1. In a range pipeline how does one handle the event of a
filter range returning empty?
2. How does one unwrap a single result from a range
Hi all,
I'm Merlin, I'm just starting out in D and super excited.
My questions are:-
1. In a range pipeline how does one handle the event of a filter
range returning empty?
2. How does one unwrap a single result from a range operation?
Look forward to your assistance!
Merlin
, but the point is, there is a rewind() method. That is
called every time on foreach().
It seems what you are after is forward ranges. Those are able
to "rewind" when you are done with them. It's just not done
through a rewind method, but via saving the range before
iteration:
```d
f
will only save the
*position* of the range, but it will not save the contents it
points to, so it will not (should not) deep-copy.
That definition is potentially misleading if we take into account
that a range is not necessarily iterating over some underlying
storage: ranges can also
n copying, even if the guts need copying
> > (unlike classes). In general, I think it was a mistake to use
> > `.save` as the mechanism, as generally `.save` is equivalent to
> > copying, so nobody does it, and code works fine for most ranges.
>
> Consider a struct whose internal f
it rarely happens. The
flaw of `save` isn't that it's an unsound API, the flaw is that
people get away with just copying, and it works 99.9% of the
time. So code is simply untested with ranges where `save` is
important.
This is very true, and makes it quite reasonable to try to pursue
"t
think it was a mistake to use `.save`
as the mechanism, as generally `.save` is equivalent to copying, so
nobody does it, and code works fine for most ranges.
Consider a struct whose internal fields are just a pointer to its "true"
internal state. Does one have any right
, as generally `.save`
is equivalent to copying, so nobody does it, and code works
fine for most ranges.
Consider a struct whose internal fields are just a pointer to its
"true" internal state. Does one have any right to assume that
the postblit/copy ctor would necessarily
1 - 100 of 1029 matches
Mail list logo
