Range of uncopyable elements

Jerry via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Dec 9 07:06:41 PST 2016


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. I'm talking about 
std library code that would have to be generic. Not user code 
where the type in the iterator is known.


> Except that C++ _does_ have special iterators. They're just not 
> as common.

Still not as common and C++ has a way to

> With the upcoming improvements to @safe and return ref, it 
> _might_ happen that there will be a way for a function to 
> accept rvalues by ref. Andrei has indicated that a really good 
> proposal might be accepted. But that's a separate issue from 
> having ref on local variables, which is what would be required 
> for what you're suggesting, and both Walter and Andrei have 
> been adamant that that is not worth it - even without getting 
> rvalue references into the mix. I don't know that it would be 
> impossible to convince them otherwise, but I would be _very_ 
> surprised if anyone managed to talk them into it.

Exactly, the problem will continue to persist even if rvalue 
references are included into D. It's not well thought out, 
isInputRange reflects that.

> And for the most part, with ranges, this is pretty much a 
> non-issue. It does become an issue when you start worrying 
> about ranges with a non-copyable front, but this is literally 
> only the second or third thread that I have ever seen where 
> anyone complained about it. Much as it is annoying when someone 
> runs int ito, it's not a big complaint that folks have. And 
> given how much of a pain it would be to deal with in general, I 
> seriously question that it's worth it - especially when simply 
> using pointers fixes the problem.

That's not an acceptable workaround. It complicates code for no 
reason. If that's the decision that is going to be accepted. Then 
there should be helper functions included in the standard to 
reflect that.



More information about the Digitalmars-d-learn mailing list