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.
