On Monday, 7 July 2014 at 12:06:21 UTC, Frédérik wrote:
Hi all,
I'm discovering the D language that seems very nice in many
aspects, but I'm quite confused by the container and range APIs
while trying to design a very simple interface-oriented API.
Especially I can't figure out how
Frédérik:
Especially I can't figure out how std.containers can connect
properly with std.ranges :
std.containers is still primitive, it needs to be improved and
fleshed out, after Andrei's memory allocators.
I would need to get the range that comes from the red black tree
(as returned by
On Monday, 7 July 2014 at 12:06:21 UTC, Frédérik wrote:
I'm trying to achieve something like that (approximate D code):
interface MyObjectSet
{
void add(MyObject o);
void SortedRange!MyObject opSlice();
}
class SomeRedBlackBasedImplementation
{
private RedBlackTree!MyObject
Meta:
(a SortedRange needs a range with random access,
I think SortedRange was recently improved, and now accepts more
than just random access ranges.
Bye,
bearophile
Thank you very much to all of you for these very quick and
precise answers !! As well as for tour recommendations about D's
idiomatisms, it seems very important to me since there are so
many available paradigms in D.
I'll try these solutions and I'll be able to go ahead with my
first D
Hi again,
The solution of making an array from the range works, but I'm
concerned about the cost of instantiating a (potentially very
large) array each time I need to walk across the set. Unless
doing that is costless in D for any reason, it does not seem
practical in my case.
And when
says that SortedRange could
accept ranges weaker than random-access, but it is unable to
provide interesting functionality for them. I don't know what to
do about this. Looks like you can't get binary search through
SortedRange over a Range of a RedBlackTree. If you don't need
that, you can just
of a RedBlackTree. If you don't need
that, you can just drop SortedRange (and assumeSorted) and use
InputRange directly.
Yes it seems this is the way to go in my case.
As far as I know, true (efficient) random access on a RB tree is
not a natural thing and I would nto have expected that ranges
coming from
On Monday, 7 July 2014 at 19:20:24 UTC, Fr wrote:
It's in the example above :
SortedRange!(MyObject[]) opSlice() {
sequence[].array.assumeSorted; }
I thought that that using .array would lead to instantiating
something.
Yes, this *will* instantiate an array and copy all of the items
from
On Monday, 7 July 2014 at 19:20:24 UTC, Fr wrote:
On Monday, 7 July 2014 at 16:58:51 UTC, anonymous wrote:
No array is created in the example. Where do you think an array
is created?
It's in the example above :
SortedRange!(MyObject[]) opSlice() {
sequence[].array.assumeSorted; }
I
On Tuesday, 10 June 2014 at 22:31:37 UTC, Nordlöw wrote:
Either way, it shouldn't be too hard to implement. Base it off
splitter!pred, which is actually quite trivial. AFAIK, your
What do you mean by basing it off splitter!pred - should I
start with some existing splitter algorithm in Phobos
On 06/11/14 00:31, Nordlöw via Digitalmars-d-learn wrote:
Either way, it shouldn't be too hard to implement. Base it off
splitter!pred, which is actually quite trivial. AFAIK, your
What do you mean by basing it off splitter!pred - should I start with some
existing splitter algorithm in
On Wednesday, 11 June 2014 at 11:42:42 UTC, Artur Skawina via
Digitalmars-d-learn wrote:
On 06/11/14 00:31, Nordlöw via Digitalmars-d-learn wrote:
Either way, it shouldn't be too hard to implement. Base it
off splitter!pred, which is actually quite trivial. AFAIK,
your
What do you mean by
On 06/11/14 14:40, monarch_dodra via Digitalmars-d-learn wrote:
For example, you should avoid countUntil and takeExactly when dealing
with strings, since these are not O(1) operations, and don't actually return
string slices. EG:
string s = someGGGreatVariableName.slicer().front;
Error:
On 06/11/14 15:44, Artur Skawina wrote:
If, instead, you create a string-specific 'countUntil' that returns
a type that holds both the byte and code-point counts and implicitly
converts to the latter, then you can have a 'takeExactly' overload
that uses the extra info to avoid the unnecessary
On Wednesday, 11 June 2014 at 13:44:25 UTC, Artur Skawina via
Digitalmars-d-learn wrote:
There is a reason why I never use D's std lib.
artur
Well, (IMO) it's a problem with no real solution. But for what
it's worth, most (if not all) of the algorithms in the standard
lib know how to handle
easier to write it that way... That is why, after seeing your solution, I wrote
the most compact lazy version I could think of - let's not scare people away
from using ranges.
AFAIUI the OP basically wanted a version of splitter that does not eat the
separators and a predicate that keeps around
I'm missing a version of splitter that can be used to split
ranges based on arbitrary predicates. I need to for conversion
between different symbol casings, typically:
1. someName = SomeName
In this case the lambda should take two arguments (a,b)
where in
1. a should be lowercase and b
1. someName = SomeName
My example is dumb and incorrect.
I actually want this to do the following
2. _someGreatVariableName = Some Great Varible Name
On Tuesday, 10 June 2014 at 21:11:17 UTC, Nordlöw wrote:
1. someName = SomeName
My example is dumb and incorrect.
I actually want this to do the following
2. _someGreatVariableName = Some Great Varible Name
The current splitter works on the notion of splitter tokens,
eg, it splits when it
On Tuesday, 10 June 2014 at 21:26:50 UTC, monarch_dodr
What exactly are you requesting though?
- Split on the edge lowercase to uppercase?
- Split on uppercase but keep the uppercase element?
Thinking about this more: Do you *actually* have two different
predicates, or are they mutually
Either way, it shouldn't be too hard to implement. Base it off
splitter!pred, which is actually quite trivial. AFAIK, your
What do you mean by basing it off splitter!pred - should I start
with some existing splitter algorithm in Phobos or start from
scratch?
Thx.
On 05/24/2014 11:01 AM, Ali Çehreli wrote:
On 05/24/2014 10:02 AM, w0rp wrote:
I have been writing my own hashmap which can provide forward ranges
usable in @safe pure nothrow functions, because it's going to be useful
for creating graph data structures with the same. I came to writing my
On 05/24/2014 10:02 AM, w0rp wrote:
Create a mutable KeyRange over a map which forwards on the right
constness for the key type, so the following must be true.
HashMap!(K, V).keys.front - K
const(HashMap!(K, V)).keys.front - const(K)
immutable(HashMap!(K, V)).keys.front - immutable(K)
I
I have been writing my own hashmap which can provide forward
ranges usable in @safe pure nothrow functions, because it's going
to be useful for creating graph data structures with the same. I
came to writing my ranges and I figured out how to do everything
right for just mutable hashmaps
On 05/24/2014 10:02 AM, w0rp wrote:
I have been writing my own hashmap which can provide forward ranges
usable in @safe pure nothrow functions, because it's going to be useful
for creating graph data structures with the same. I came to writing my
ranges and I figured out how to do everything
On Saturday, 24 May 2014 at 18:01:43 UTC, Ali Çehreli wrote:
On 05/24/2014 10:02 AM, w0rp wrote:
I have been writing my own hashmap which can provide forward
ranges
usable in @safe pure nothrow functions, because it's going to
be useful
for creating graph data structures with the same. I
In this case I am not sure about bug reports, so I ask here.
In this program the first loop doesn't compile, giving a nice
error:
test.d(3,5): Error: index type 'ubyte' cannot cover index range
0..300
If you comment out the first loop, the second compiles and runs,
but it seems to go in
For the second loop one possible alternative behavour is to
refuse a ubyte index and accept only a size_t index if it loops
on a dynamic array.
Another alternative is: the i variable can go from 0 to 255,
then go up to the modulus of the remaining indexes, and then
stop.
In this program the
On Mon, 21 Apr 2014 07:49:03 -0400, bearophile bearophileh...@lycos.com
wrote:
In this case I am not sure about bug reports, so I ask here.
In this program the first loop doesn't compile, giving a nice error:
test.d(3,5): Error: index type 'ubyte' cannot cover index range 0..300
If you
https://issues.dlang.org/show_bug.cgi?id=12611
Bye,
bearophile
On 03/28/2014 08:00 PM, H. S. Teoh wrote:
Today I ran into an interesting situation where I have a function f that
needs to return ranges of different types (but identical element types):
auto f(A...)(A args) {
...
if (someCondition
On 03/29/2014 01:37 AM, Artur Skawina wrote:
You can wrap the range in a common one. When the above approach isn't
enough, there's always the next level:
(Note that your code does not actually compile.)
On 03/29/14 16:31, Timon Gehr wrote:
On 03/29/2014 01:37 AM, Artur Skawina wrote:
You can wrap the range in a common one. When the above approach isn't
enough, there's always the next level:
(Note that your code does not actually compile.)
Of course it compiles -- with the compiler version
On 03/29/2014 06:19 PM, Artur Skawina wrote:
Of course it compiles -- with the compiler version I happen to use...
The compiler situation is one of the main reasons I gave up on D
about a year ago. Every release introduces a new dialect. This may
not be such a big problem for trivial toy
On 03/29/14 18:30, Timon Gehr wrote:
I'm stuck with 2.060 myself, but there's always http://dpaste.dzfl.pl/.
For the examples, I used a gdc that claims __VERSION__==2062L.
(for /real/ code I'm still using a 2.057 based one...)
artur
On 03/28/2014 08:00 PM, H. S. Teoh wrote:
Today I ran into an interesting situation where I have a function f
that needs to return ranges of different types (but identical element
types):
auto f(A...)(A args) {
...
if (someCondition
Today I ran into an interesting situation where I have a function f that
needs to return ranges of different types (but identical element types):
auto f(A...)(A args) {
...
if (someCondition)
return cartesianProduct(x, y
On Friday, 28 March 2014 at 19:02:48 UTC, H. S. Teoh wrote:
Today I ran into an interesting situation where I have a
function f that
needs to return ranges of different types (but identical
element types):
auto f(A...)(A args) {
...
if (someCondition
H. S. Teoh:
So how would I implement something like this?
One option is to wrap those ranges in classes. See std.range for
the adapters. (I have not used them yet).
Bye,
bearophile
On 03/28/2014 01:46 PM, bearophile wrote:
H. S. Teoh:
So how would I implement something like this?
One option is to wrap those ranges in classes. See std.range for the
adapters. (I have not used them yet).
Link:
http://dlang.org/phobos/std_range.html#.inputRangeObject
Short examples
On 03/28/14 20:00, H. S. Teoh wrote:
Today I ran into an interesting situation where I have a function f that
needs to return ranges of different types (but identical element types):
auto f(A...)(A args) {
...
if (someCondition
On Fri, Mar 28, 2014 at 10:44:11PM +0100, Artur Skawina wrote:
On 03/28/14 20:00, H. S. Teoh wrote:
Today I ran into an interesting situation where I have a function f
that needs to return ranges of different types (but identical
element types):
auto f(A...)(A args
, vs. an alternative
algorithm
filtered by some other filters.
T
That would have been my solution too (though maybe using a
delegate, to not re-evaluate someconditon per-element).
If both ranges are completely incompatible, then I'd either:
- array them into submission until they reach
On 03/28/14 23:10, H. S. Teoh wrote:
On Fri, Mar 28, 2014 at 10:44:11PM +0100, Artur Skawina wrote:
On 03/28/14 20:00, H. S. Teoh wrote:
Today I ran into an interesting situation where I have a function f
that needs to return ranges of different types (but identical
element types):
auto
in
the caller:
auto polymorphicRange(size_t i, R...)(R ranges)
{
static if (i==0)
return ranges[0];
else static if (i==1)
return ranges[1];
else ... // etc
}
void processRange(R)(R
I see that ranges is primitive to organzie universal approach to
write some algorithms. But I'm using algorithms from the library
but I still can't start with writing my own algorithms based on
ranges. For example I have the following function written without
ranges. I want to improve
On Monday, 24 March 2014 at 12:13:43 UTC, Uranuz wrote:
I see that ranges is primitive to organzie universal approach
to write some algorithms. But I'm using algorithms from the
library but I still can't start with writing my own algorithms
based on ranges. For example I have the following
Have you read this: http://ddili.org/ders/d.en/ranges.html ?
Yes I have read it. It's difficult to formulate the question in
English bu I'l try. In this example I searching for special
symbols '' and '='. So when symbol found I use *save* method of
range to remember start of *name* or
don't know all of it's possibilities/
advantages. It's why I asking.
In my algorithms for parsing some strings I often save positions
of beginings of some tokens in order to take a slice and put it
into some buffer. But for opearting with them in terms of ranges
I need to have RandomAccessRange
On Monday, 24 March 2014 at 14:12:58 UTC, Uranuz wrote:
Have you read this: http://ddili.org/ders/d.en/ranges.html ?
Yes I have read it. It's difficult to formulate the question in
English bu I'l try. In this example I searching for special
symbols '' and '='. So when symbol found I use
Luís Marques:
It would swap elements, like sort, so it doesn't need to put
them anywhere, just permute them. The advantage is this:
Input: [7, 3, 7, 1, 1, 1, 1]
Output sort: [1, 1, 1, 1, 3, 7, 7]
Output groupSort: [3, 7, 7, 1, 1, 1, 1]
I think to swap items it must know where to swap them
Is there a neat way to do this transformation with ranges and
std.algorithms?
Input:
---
B foo
B bar
C ble
B big
A begga
Output: (aggregated and sorted on length)
---
B - [foo, bar, big]
C - [ble]
A - [begga]
The most obvious way (to me
Luís Marques:
Is there a neat way to do this transformation with ranges and
std.algorithms?
Input:
---
B foo
B bar
C ble
B big
A begga
Output: (aggregated and sorted on length)
---
B - [foo, bar, big]
C - [ble]
A - [begga]
What
On Friday, 21 March 2014 at 15:38:23 UTC, bearophile wrote:
Output: (aggregated and sorted on length)
---
B - [foo, bar, big]
C - [ble]
A - [begga]
What is the desired output data structure? An associative array
of dynamic arrays? Or is a dynamic arrays of dynamic arrays of
Luís Marques:
So let's just say that the client is unclear on his
requirements, which does happen in the real world anyway :-).
Yes, it happens, But it's a problem, because often if you know
what you need you can produce the results more efficiently :-)
(did anyone actually implement
On Friday, 21 March 2014 at 16:04:45 UTC, bearophile wrote:
I think this problem needs a sorting or a hash. One possible
solution, if you don't need an associative array as output, is
to use a multiSort followed by a building of groups using
slicing. It could be efficient enough. Later you
On Fri, 21 Mar 2014 15:22:13 +, Luís Marques wrote:
Is there a neat way to do this transformation with ranges and
std.algorithms?
Input:
---
B foo B bar C ble B big A begga
Output: (aggregated and sorted on length)
---
B - [foo, bar, big
range
of lazy ranges.
1 https://github.com/D-Programming-Language/phobos/pull/1186
Be aware, though, that groupBy only compares *adjacent* elements for
equivalence; it does not sort the input. So if your input has equivalent
elements interspersed with non-equivalent elements, you will have
On Friday, 21 March 2014 at 16:53:46 UTC, H. S. Teoh wrote:
Be aware, though, that groupBy only compares *adjacent*
elements for
equivalence; it does not sort the input. So if your input has
equivalent
elements interspersed with non-equivalent elements, you will
have the
equivalent elements
On Friday, 21 March 2014 at 17:20:38 UTC, Luís Marques wrote:
I think that's why Justin used sort. The hashGroupBy proposed
by bearophile would avoid the sort and the additional memory
usage though, so that would be even better.
I was thinking, we don't even need the full power of sort. Is
Luís Marques:
I was thinking, we don't even need the full power of sort. Is
there a standard algorithm that makes elements with equal keys
be in sequence, but that otherwise is less expensive than sort?
I don't know any, how is it supposed to know where to group
items? Usually you build an
On Saturday, 22 March 2014 at 01:08:11 UTC, bearophile wrote:
how is it supposed to know where to group items? Usually you
build an associative array for that.
It would swap elements, like sort, so it doesn't need to put them
anywhere, just permute them. The advantage is this:
Input: [7, 3,
Is it, in D today, possible to explicitly tag higher order ranges
such as for example `map` with their pureness, safeness and
throwness based on the corresponding properties on their function
arguments such as `fun...`?
And is this motivated? now that the D compiler deduce these
properties
On Monday, March 10, 2014 22:02:39 Nordlöw wrote:
Is it, in D today, possible to explicitly tag higher order ranges
such as for example `map` with their pureness, safeness and
throwness based on the corresponding properties on their function
arguments such as `fun...`?
And is this motivated
I'm not quite sure what you're asking. You either mark a
function as @safe,
pure, and/or nothrow - or you don't, in which case, if it's a
templated
function, the attributes are inferred to the best of the
compiler's
capabilities, and if it's not, then the function doesn't have
those
it is a
count or index into the result set.
Lets call this change scheme #0. It solves my issue, and interestingly
also would have meant we didn't need to add byKey or byValue to AA's,
instead we could have simply made keys/values indexable ranges and not
broken any existing code.
Further details
On Fri, 14 Feb 2014 02:48:51 -, Jesse Phillips
jesse.k.phillip...@gmail.com wrote:
On Thursday, 13 February 2014 at 14:30:41 UTC, Regan Heath wrote:
Don't get me wrong, counting the elements as you iterate over them is
useful, but it isn't the index into the range you're likely after.
a function on a range and
foreaching on the result, you would intuitively and immediately
expect 'i' to relate to the result, not the input.
R
How should it behave on ranges without length, such as infinite
ranges?
Also, `enumerate` has the advantage of the `start` parameter,
which usefulness
Regan Heath:
FWIW I disagree. I think it's immediately and intuitively
obvious what 'i' should be when you're foreaching over X items
taken from another range, even if you do not know take returns
another range. Compare it to calling a function on a range and
foreaching on the result, you
On Fri, 14 Feb 2014 13:14:51 -, bearophile bearophileh...@lycos.com
wrote:
Regan Heath:
FWIW I disagree. I think it's immediately and intuitively obvious what
'i' should be when you're foreaching over X items taken from another
range, even if you do not know take returns another
, even if you do not know take returns another range. Compare it
to calling a function on a range and foreaching on the result, you
would intuitively and immediately expect 'i' to relate to the result,
not the input.
R
How should it behave on ranges without length, such as infinite ranges
Regan Heath:
In my case I didn't need any of these.
I don't understand.
Bye,
bearophile
Isn't this discussion about adding an index to a range? If it is,
then I have shown why adding it in the language is a bad idea.
Bye,
bearophile
for arrays:
foreach(v; [1,2,3,4])
writeln(v);
foreach(i, v; [1,2,3,4])
writeln(i, = , v);
But for ranges, the second form is not possible:
foreach(v; iota(4)) // ok
writeln(v);
foreach(i, v; iota(4))// Error: cannot infer argument
types
writeln(i, = , v);
Marc Schütz:
As far as I understand it, it's about adding an index to
_foreach_, as is already supported for arrays:
foreach(v; [1,2,3,4])
writeln(v);
foreach(i, v; [1,2,3,4])
writeln(i, = , v);
But for ranges, the second form is not possible:
foreach(v; iota(4)) // ok
On Wed, 12 Feb 2014 11:08:57 -, Jakob Ovrum jakobov...@gmail.com
wrote:
On Wednesday, 12 February 2014 at 10:44:57 UTC, Regan Heath wrote:
Ahh.. so this is a limitation of the range interface. Any plans to
fix this?
R
Did my original reply not arrive? It is the first reply in the
order (personally haven't seen such a
range). But more importantly you're not dealing with random access
ranges. The index you're receiving from take(5) can't be used on the
range.
A forward range can do what I am describing above, it's trivial.
Don't get me wrong, counting the elements as you
On Thursday, 13 February 2014 at 14:30:41 UTC, Regan Heath wrote:
Don't get me wrong, counting the elements as you iterate over
them is useful, but it isn't the index into the range you're
likely after.
Nope, not what I am after. If I was, I'd iterate over the
original range instead or keep
On Tue, 11 Feb 2014 17:11:46 -, Ali Çehreli acehr...@yahoo.com wrote:
On 02/11/2014 06:25 AM, Rene Zwanenburg wrote:
On Tuesday, 11 February 2014 at 10:10:27 UTC, Regan Heath wrote:
foreach (i, line; range.take(4)) //Error: cannot infer argument
types
{
..etc..
}
foreach
parameters.
byLine has its own issues with reuse of the buffer, it isn't inherent to
ranges. I haven't really used it (needed it from std.process), when I
wanted to read a large file I went with wrapping std.mmap:
https://github.com/JesseKPhillips/libosm/blob/master/source/util/filerange.d
Cool
On Wednesday, 12 February 2014 at 10:44:57 UTC, Regan Heath wrote:
Ahh.. so this is a limitation of the range interface. Any
plans to fix this?
R
Did my original reply not arrive? It is the first reply in the
thread...
Reproduced:
See this pull request[1] and the linked enhancement
Things like this should just work..
File input ...
auto range = input.byLine();
while(!range.empty)
{
range.popFront();
foreach (i, line; range.take(4)) //Error: cannot infer argument types
{
..etc..
}
range.popFront();
}
Tried adding 'int' and 'char[]' or 'auto' .. no dice.
On Tuesday, 11 February 2014 at 10:10:27 UTC, Regan Heath wrote:
Things like this should just work..
File input ...
auto range = input.byLine();
while(!range.empty)
{
range.popFront();
foreach (i, line; range.take(4)) //Error: cannot infer
argument types
{
..etc..
}
On Tuesday, 11 February 2014 at 10:10:27 UTC, Regan Heath wrote:
Things like this should just work..
File input ...
auto range = input.byLine();
while(!range.empty)
{
range.popFront();
foreach (i, line; range.take(4)) //Error: cannot infer
argument types
{
..etc..
}
On Tue, 11 Feb 2014 10:52:39 -, Tobias Pankrath tob...@pankrath.net
wrote:
Further, the naive solution of adding .array gets you in all sorts of
trouble :p (The whole byLine buffer re-use issue).
This should be simple and easy, dare I say it trivial.. or am I just
being dense here.
On Tue, 11 Feb 2014 10:58:17 -, Tobias Pankrath tob...@pankrath.net
wrote:
On Tuesday, 11 February 2014 at 10:10:27 UTC, Regan Heath wrote:
Things like this should just work..
File input ...
auto range = input.byLine();
while(!range.empty)
{
range.popFront();
foreach (i, line;
On Tuesday, 11 February 2014 at 13:00:19 UTC, Regan Heath wrote:
import std.stdio;
struct S1 {
private int[] elements = [9,8,7];
int opApply (int delegate (ref uint, ref int) block) {
foreach (uint i, int n ; this.elements)
block(i, n);
return 0;
}
}
void
On Tuesday, 11 February 2014 at 10:10:27 UTC, Regan Heath wrote:
Things like this should just work..
File input ...
auto range = input.byLine();
while(!range.empty)
{
range.popFront();
foreach (i, line; range.take(4)) //Error: cannot infer
argument types
{
..etc..
}
On 02/11/2014 06:25 AM, Rene Zwanenburg wrote:
On Tuesday, 11 February 2014 at 10:10:27 UTC, Regan Heath wrote:
foreach (i, line; range.take(4)) //Error: cannot infer argument types
{
..etc..
}
foreach (i, line; iota(size_t.max).zip(range.take(4)))
{
}
There is also the
On Tuesday, 11 February 2014 at 10:52:40 UTC, Tobias Pankrath
wrote:
The second naive solution would be to use readText and
splitLines.
That's the sort of thing I always do because then I understand
what's going on, and when there's a bug I can find it easily!
But then I'm not writing
On Tuesday, 11 February 2014 at 19:48:41 UTC, Jesse Phillips
wrote:
In case the other replies weren't clear enough. A range does
not have an index.
What do you expect 'i' to be?
In case of foreach(i, x; range) I would expect it to be iteration
number of this particular foreach. I miss it
I'm searching the docs for something similar to:
copy(someInputRange, firstOutputRange, secondOutputRange, );
I know how to write it by hand, but I'm suspecting that something like
this is already in phobos.
And secondly, is there some function that gives me a forward range to
some input
On Monday, 27 January 2014 at 17:26:35 UTC, Robert Schadek wrote:
I'm searching the docs for something similar to:
copy(someInputRange, firstOutputRange, secondOutputRange, );
I know how to write it by hand, but I'm suspecting that
something like
this is already in phobos.
Hi, I think
, is there some function that gives me a forward range to
some input range?
Curiously, copy doesn't implement multiple output ranges. I don't think
there's any reason it couldn't. I think an enhancement request is in
order.
Turning an InputRange into a ForwardRange implies buffering,
std.array.array
I posted a question on stackoverflow about the cartesian product
of immutable ranges :
http://stackoverflow.com/questions/21368501/cartesian-product-of-immutable-ranges
There are a lot of various thing I don't understand.
This code compiles and run :
import std.stdio;
import std.range
of two immutable ranges ?
Short answer: with std.algorithm - you can't. Because internally
it (Zip, actually) performs assignments, and you can't assign to
immutable(T).
Why?
); // will print immutable(int)[]
You mean that two input ranges are created from the immutable
arrays when I call the function ?
Zip doesn't compiles while zip compile. :/
Here is the implementation of zip :
auto zip(Ranges...)(Ranges ranges)
if (Ranges.length allSatisfy!(isInputRange, Ranges
On Sunday, 26 January 2014 at 22:32:32 UTC, matovitch wrote:
You mean that two input ranges are created from the immutable
arrays when I call the function ?
Zip doesn't compiles while zip compile. :/
`Zip` must be explicitly instantiated, which allows you to
attempt to instantiate
On Sunday, 26 January 2014 at 22:52:56 UTC, Jakob Ovrum wrote:
On Sunday, 26 January 2014 at 22:32:32 UTC, matovitch wrote:
You mean that two input ranges are created from the immutable
arrays when I call the function ?
Zip doesn't compiles while zip compile. :/
`Zip` must be explicitly
501 - 600 of 1029 matches
Mail list logo
