On Saturday, 20 June 2020 at 04:34:42 UTC, H. S. Teoh wrote:
> On Fri, Jun 19, 2020 at 09:14:30PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
>> One good goal for std.v2020 would be to forego autodecoding throughout.
> [...]
>
> Another could be to fix up the range API -- i.e, reconsider the ugliness that is .save, now that D has copy ctors.

How do you see that? Fundamentally, what have copy ctors changed in this regard?

On Saturday, 20 June 2020 at 09:49:38 UTC, Stanislav Blinov wrote:
> On Saturday, 20 June 2020 at 04:34:42 UTC, H. S. Teoh wrote:
>> On Fri, Jun 19, 2020 at 09:14:30PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
>>> One good goal for std.v2020 would be to forego autodecoding throughout.
>> [...]
>>
>> Another could be to fix up the range API -- i.e, reconsider the ugliness that is .save, now that D has copy ctors.
>
> How do you see that? Fundamentally, what have copy ctors changed in this regard?

I suppose that postblit has had various implementation and language design issues (which copy constructors address), which prevented them from being a reliable alternative to save(). This and probably also class support.

On Saturday, 20 June 2020 at 04:34:42 UTC, H. S. Teoh wrote:
> On Fri, Jun 19, 2020 at 09:14:30PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
>> One good goal for std.v2020 would be to forego autodecoding throughout.
> [...]
>
> Another could be to fix up the range API -- i.e, reconsider the ugliness that is .save, now that D has copy ctors.
>
>
> T

Also, switch from `void popFront()` to `typeof(this) rest`, so that we can have `const` and `immutable` ranges.

On Saturday, 20 June 2020 at 10:03:06 UTC, Petar Kirov [ZombineDev] wrote:
> On Saturday, 20 June 2020 at 09:49:38 UTC, Stanislav Blinov wrote:
>> On Saturday, 20 June 2020 at 04:34:42 UTC, H. S. Teoh wrote:

>>> Another could be to fix up the range API -- i.e, reconsider the ugliness that is .save, now that D has copy ctors.
>>
>> How do you see that? Fundamentally, what have copy ctors changed in this regard?
>
> I suppose that postblit has had various implementation and language design issues (which copy constructors address), which prevented them from being a reliable alternative to save(). This and probably also class support.

All ranges are supposed to be copyable, so their copy-ability is not sufficient to distinguish input and forward ranges. Whether it's postblit or copy ctor makes no difference here, unless I'm missing something.

On Saturday, 20 June 2020 at 10:52:37 UTC, Stanislav Blinov wrote:
> On Saturday, 20 June 2020 at 10:03:06 UTC, Petar Kirov [ZombineDev] wrote:
>> On Saturday, 20 June 2020 at 09:49:38 UTC, Stanislav Blinov wrote:
>>> On Saturday, 20 June 2020 at 04:34:42 UTC, H. S. Teoh wrote:
>
>>>> Another could be to fix up the range API -- i.e, reconsider the ugliness that is .save, now that D has copy ctors.
>>>
>>> How do you see that? Fundamentally, what have copy ctors changed in this regard?
>>
>> I suppose that postblit has had various implementation and language design issues (which copy constructors address), which prevented them from being a reliable alternative to save(). This and probably also class support.
>
> All ranges are supposed to be copyable, so their copy-ability is not sufficient to distinguish input and forward ranges. Whether it's postblit or copy ctor makes no difference here, unless I'm missing something.

As far as I know, back when the ranges API was worked on postblit ctors didn't work reliably, so .save() was the only option. If it had worked, we could require that non-forward ranges are non-copyable.

On Saturday, 20 June 2020 at 10:43:41 UTC, Paul Backus wrote:
> On Saturday, 20 June 2020 at 04:34:42 UTC, H. S. Teoh wrote:
>> On Fri, Jun 19, 2020 at 09:14:30PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
>>> One good goal for std.v2020 would be to forego autodecoding throughout.
>> [...]
>>
>> Another could be to fix up the range API -- i.e, reconsider the ugliness that is .save, now that D has copy ctors.
>>
>>
>> T
>
> Also, switch from `void popFront()` to `typeof(this) rest`, so that we can have `const` and `immutable` ranges.

Yes!

On Saturday, 20 June 2020 at 10:43:41 UTC, Paul Backus wrote:
> [snip]
>
> Also, switch from `void popFront()` to `typeof(this) rest`, so that we can have `const` and `immutable` ranges.

Would typeof(this) work where popFront is currently a free-standing function, like with built-in dynamic arrays?

On Saturday, 20 June 2020 at 12:05:18 UTC, jmh530 wrote:
> On Saturday, 20 June 2020 at 10:43:41 UTC, Paul Backus wrote:
>> [snip]
>>
>> Also, switch from `void popFront()` to `typeof(this) rest`, so that we can have `const` and `immutable` ranges.
>
> Would typeof(this) work where popFront is currently a free-standing function, like with built-in dynamic arrays?

typeof(this) is only possible for member function based implementations. Otherwise the implementation for arrays would be:

inout(T)[] rest(T)(input(T)[] array) { return array[1 .. $]; }

https://run.dlang.io/gist/run-dlang/7a4e5872ee26c083b916303fe36ac43b?compiler=dmd

On Saturday, 20 June 2020 at 11:20:13 UTC, Petar Kirov [ZombineDev] wrote:

> As far as I know, back when the ranges API was worked on postblit ctors didn't work reliably, so .save() was the only option.

Funny that, at the moment it's the copy ctors that aren't working reliably (e.g. they're not working at all with arrays). :)

> If it had worked, we could require that non-forward ranges are non-copyable.

I can imagine this would be quite some work to adapt all of Phobos to *that*. I mean, things like

auto rem = makeSomeInputRange.find!pred;
auto flt = makeSomeInputRange.filter!pred;

Those would not compile. They could be made to compile by `move`ing the argument for the return. But then you still won't be able to pass those results around, unless via a refRange or `move`.

On Saturday, 20 June 2020 at 10:43:41 UTC, Paul Backus wrote:

> Also, switch from `void popFront()` to `typeof(this) rest`, so that we can have `const` and `immutable` ranges.

*Switch* is probably too restrictive. For a given range a `popFront` may be more efficient than a `range = range.rest`. Making `rest` a valid range primitive though, and using where appropriate - that'd be awesome.