Re: Range of uncopyable elements

2016-12-09 Thread Jerry via Digitalmars-d-learn
On Thursday, 8 December 2016 at 23:08:35 UTC, Jonathan M Davis wrote: I've seen that in C++ code all the time, especially if you're dealing with smart pointers, because otherwise you have to do stuff like (*iter)->foo() instead of just var->foo(). Smart pointers weren't introduced until C++11

Re: Range of uncopyable elements

2016-12-08 Thread Jonathan M Davis via Digitalmars-d-learn
On Thursday, December 08, 2016 22:32:47 Jerry via Digitalmars-d-learn wrote: > On Thursday, 8 December 2016 at 21:46:26 UTC, Jonathan M Davis > > wrote: > > However, at least as of C++98, non-copyable elements in a > > container were not allowed IIRC, so it would have been pretty > > rare to have a

Re: Range of uncopyable elements

2016-12-08 Thread Jerry via Digitalmars-d-learn
On Thursday, 8 December 2016 at 21:46:26 UTC, Jonathan M Davis wrote: However, at least as of C++98, non-copyable elements in a container were not allowed IIRC, so it would have been pretty rare to have a C++ iterator that returned a non-copyable value when you dereferenced it. Even if it was u

Re: Range of uncopyable elements

2016-12-08 Thread Jonathan M Davis via Digitalmars-d-learn
On Thursday, December 08, 2016 20:21:41 Jerry via Digitalmars-d-learn wrote: > Assuming that is wrong though, as you aren't copying an iterator > or range you are copying the actual value. What you are confusing > "auto h = r.front;" for is this: "auto rcopy = r;". The D code > "auto h = r.front" i

Re: Range of uncopyable elements

2016-12-08 Thread Jerry via Digitalmars-d-learn
On Thursday, 8 December 2016 at 17:29:42 UTC, H. S. Teoh wrote: The problem is that most range algorithms won't work if `auto h = r.front;` doesn't compile. Random chunks of std.algorithm won't work for such a range. One may argue, of course, that std.algorithm ought to be fixed... but the r

Re: Range of uncopyable elements

2016-12-08 Thread H. S. Teoh via Digitalmars-d-learn
On Thu, Dec 08, 2016 at 05:22:25PM +, Jerry via Digitalmars-d-learn wrote: > On Thursday, 8 December 2016 at 16:48:07 UTC, H. S. Teoh wrote: > > On Thu, Dec 08, 2016 at 04:35:02PM +, Jerry via Digitalmars-d-learn > > wrote: > > > The problem is with how isInputRange is defined, requires tha

Re: Range of uncopyable elements

2016-12-08 Thread Jerry via Digitalmars-d-learn
On Thursday, 8 December 2016 at 16:48:07 UTC, H. S. Teoh wrote: On Thu, Dec 08, 2016 at 04:35:02PM +, Jerry via Digitalmars-d-learn wrote: The problem is with how isInputRange is defined, requires that front be copyable. auto h = r.front; // can get the front of the range https://github.c

Re: Range of uncopyable elements

2016-12-08 Thread H. S. Teoh via Digitalmars-d-learn
On Thu, Dec 08, 2016 at 04:35:02PM +, Jerry via Digitalmars-d-learn wrote: > The problem is with how isInputRange is defined, requires that front > be copyable. > > auto h = r.front; // can get the front of the range > > https://github.com/dlang/phobos/blob/v2.072.1/std/range/primitives.d#L16

Re: Range of uncopyable elements

2016-12-08 Thread Jerry via Digitalmars-d-learn
The problem is with how isInputRange is defined, requires that front be copyable. auto h = r.front; // can get the front of the range https://github.com/dlang/phobos/blob/v2.072.1/std/range/primitives.d#L168 It doesn't take into consideration that front exists and that it's a reference to a s

Range of uncopyable elements

2016-12-08 Thread RazvanN via Digitalmars-d-learn
Hi, I am trying to create a range with uncopyable elements. My thought process was the following: 1.I have created a struct : struct S { int a; @disable this(this); } 2. I declared an array : S[] arr = [S(1), S(2), S(3)]; expecting that arr will be a range like, for example, an in