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

[Namespace via Digitalmars-d]

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
----
?