On 21 October 2016 at 06:57, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 10/20/2016 12:49 PM, Andrei Alexandrescu wrote:
>
>> On 10/20/2016 06:23 AM, Ethan Watson wrote:
>>
>>> Suitable enough for simple functions. But beyond that becomes maintenance hell.
>>>
>>
>> I agree this workaround has a combinatorial problem.
>>
>
> Yes, Ethan made a good point I hadn't thought of.


Shoot me! ;)

On 10/21/2016 01:18 AM, Nicholas Wilson wrote:
> Is it legal to `.save` a const range, and then use it (provided it does
> not mutate any object reachable from bar)?

Sure, if it doesn't involve a cast, i.e. if save is const.

On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote:
> I think a solid DIP addressing the problem would have a good chance to get traction.

I think all the information in this thread and the "Binding rvalues to const ref in D" thread that Atilla started is enough for me to write up a solid DIP.

I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for comment/input this weekend before posting it properly.

On 10/21/2016 12:56 AM, Ethan Watson wrote:
> I'll start doing that. Hopefully I'll get a draft up that I'll pass to Manu for
> comment/input this weekend before posting it properly.

Great!

On Thursday, October 20, 2016 23:18:14 Nicholas Wilson via Digitalmars-d wrote:
> On Thursday, 20 October 2016 at 01:04:35 UTC, Jonathan M Davis
>
> wrote:
> > The transitivity of const shoot stuff in the foot pretty thoroughly in a number of cases. A prime example would be ranges, because they have to be mutated to be iterated over. If the function actually took a range directly, you wouldn't bother with const ref, but it could be an object that contains a range, and because you can't normally get a tail-const range from a const range (aside from dynamic arrays), it can become quite difficult to actually iterate over the range. e.g.
> >
> > auto foo(ref const(Bar) bar)
> > {
> >
> >     auto range = bar.getSomeRange();
> >     ...
> >
> > }
>
> Is it legal to `.save` a const range, and then use it (provided it does not mutate any object reachable from bar)?

Not really. isForwardRange requires that save return _exactly_ the same type as the range. So, it really can't work as a const function (and const(MyRangeType) will never pass isInputRange or isFowardRange, because popFront won't compile). You _can_ declare an overload of save that's const and returns something different, but then it's not actually part of the range API, and you can't rely on it working. At that point, you might as well make up your own function, since what you're doing is non-standand anyway.

Regardless of all that though, it's not always even possible for a range to have a function that returns a tail-const version of the range because of how the internals of the range work. So, even if we had a standard way to deal with that, it couldn't work in all cases, and really, it would have to be dealt with separately from traits like isForwardRange. Arguably, to match arrays, we should be defining an opSlice for ranges which returns a tail-const version of the range (and then we could have a trait like hasTailConstSlicing), but that's not currently part of the range API, and it's actually pretty hard to define even for simple ranges (e.g. you have to use static if carefully to avoid recursive template instantiations).

So, the best way to handle this is very much an open question. For now, the reality of the matter is that there is no standard way for const ranges to work.

- Jonathan M Davis

On 10/21/2016 04:47 AM, Walter Bright wrote:
> On 10/21/2016 12:56 AM, Ethan Watson wrote:
>> I'll start doing that. Hopefully I'll get a draft up that I'll pass to
>> Manu for
>> comment/input this weekend before posting it properly.
>
> Great!

I, too, will look forward to that. If we get it right, we'll have a prototype of a good DIP to serve as an example for future submissions.

By the way, the deadline for looking at https://github.com/dlang/DIPs/blob/master/DIPs/DIP1001.md and https://github.com/dlang/DIPs/blob/master/DIPs/DIP1002.md is October 30, please make sure it is as good as it can be before that.


Thanks,

Andrei

On 21.10.2016 09:56, Ethan Watson wrote:
> On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote:
>> I think a solid DIP addressing the problem would have a good chance to
>> get traction.
>
> I think all the information in this thread and the "Binding rvalues to
> const ref in D" thread that Atilla started is enough for me to write up
> a solid DIP.
>
> I'll start doing that. Hopefully I'll get a draft up that I'll pass to
> Manu for comment/input this weekend before posting it properly.

Nice! Make sure it is orthogonal to const. :)

On 10/21/16 5:39 PM, Timon Gehr wrote:
> On 21.10.2016 09:56, Ethan Watson wrote:
>> On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote:
>>> I think a solid DIP addressing the problem would have a good chance to
>>> get traction.
>>
>> I think all the information in this thread and the "Binding rvalues to
>> const ref in D" thread that Atilla started is enough for me to write up
>> a solid DIP.
>>
>> I'll start doing that. Hopefully I'll get a draft up that I'll pass to
>> Manu for comment/input this weekend before posting it properly.
>
> Nice! Make sure it is orthogonal to const. :)

It would be great if you participated. Such a DIP needs you. -- Andrei

On 22.10.2016 03:10, Andrei Alexandrescu wrote:
> On 10/21/16 5:39 PM, Timon Gehr wrote:
>> On 21.10.2016 09:56, Ethan Watson wrote:
>>> On Thursday, 20 October 2016 at 19:49:42 UTC, Andrei Alexandrescu wrote:
>>>> I think a solid DIP addressing the problem would have a good chance to
>>>> get traction.
>>>
>>> I think all the information in this thread and the "Binding rvalues to
>>> const ref in D" thread that Atilla started is enough for me to write up
>>> a solid DIP.
>>>
>>> I'll start doing that. Hopefully I'll get a draft up that I'll pass to
>>> Manu for comment/input this weekend before posting it properly.
>>
>> Nice! Make sure it is orthogonal to const. :)
>
> It would be great if you participated. Such a DIP needs you. -- Andrei
>

I'm ready to participate (but I can't invest too much time at the moment). Are we going with @rvalue ref?

On Saturday, October 22, 2016 23:13:28 Timon Gehr via Digitalmars-d wrote:
> I'm ready to participate (but I can't invest too much time at the moment). Are we going with @rvalue ref?

That would certainly be my preference - at least out of what's been discussed thus far.

- Jonathan M Davis