Better handling of noncopyable objects and objects with this(this)

[Jonathan M Davis via Digitalmars-d]

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