Generality creep

[ag0aep6g]

On 29.03.19 00:30, Walter Bright wrote:
> The problem I ran into was ranges that had const fields would fail, 
> because one cannot assign to a const field. But one can construct a 
> const field. Doing some digging, it became apparent that save() is 
> equivalent to copy construction, and so should be implemented using copy 
> construction.

Is Phobos supposed to support ranges with const fields? Won't that be 
generality creep?

A quick test shows that all five examples from issue 18657 fail for 
ranges with const fields. With my changes, the first three work, and the 
other two don't fail in `save` anymore, but still in other places.

Supporting const fields will require at least the same amount of 
busywork as supporting RefRange, because the underlying issue is the 
same: Can ranges be non-assignable and should Phobos support such ranges?

[...]
> Fixing RefRange.save() using copy construction, and ditching opAssign, 
> would be acceptable.

How does RefRange.save need fixing?