Generality creep

[Walter Bright]

On 3/28/2019 5:40 PM, ag0aep6g wrote:
> 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?

Phobos already has such ranges, such as Repeat.

Besides, if you accept the notion that save() performs a construction, not an 
assignment, and that construction and assignment are fundamentally different, 
then save() must be implemented using construction.

I can't think of a case where this would break existing code.


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

Ranges don't need to be assignable. ForwardRanges need to supply a save(), which 
means copy construction, not assignment.


>> Fixing RefRange.save() using copy construction, and ditching opAssign, would 
>> be acceptable.
> 
> How does RefRange.save need fixing?

I thought you wrote that copy construction would make RefRange work?