On Monday, 1 June 2015 at 10:18:35 UTC, Jonathan M Davis wrote:
On Monday, 1 June 2015 at 04:43:20 UTC, Andrei Alexandrescu
wrote:
FYI I just created
https://issues.dlang.org/show_bug.cgi?id=14638 as one of
possibly several language enhancements to improve usability of
noncopyable types (most allocators are not copyable) and to
enhance performance of objects that define this(this). --
Andrei
On a related note, as was brought up recently (by Ketmar IIRC),
ranges currently forbid noncopyable objects thanks to
auto h = r.front; // can get the front of the range
in isInputRange. If we want to fix that, then we're probably
going to need to change isInputRange so that it checks that we
can access front but doesn't require copying and then add
something like hasCopyableElements for the algorithms that do
need to copy front. I'm not a huge fan of that idea given how
much code exists which copies front and how that would likely
require that a lot of range-based functions add even more
checks to their template constraints, but I'm not sure what
else we can reasonably do if we want noncopyable elements to
work in ranges, and the change wouldn't break existing code,
just make it so that much of it would need updated template
constraints in order to avoid compilation errors if anyone ever
tries to use a range with noncopyable elements with it.
- Jonathan M Davis
What about
----
auto h = &r.front; // can get the front of the range
----
?
