On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote:
> There is a rub though. Not only you're telling what we'd need to do to be more successful, you're also telling us how to do it. Please don't. We are not adding type qualifiers to D if we can avoid it, and generally we want to achieve what we need to achieve with minimum aggravation. Instead please focus on what you're trying to accomplish, not on whether an artifact is a type qualifier or a storage class. Thanks.
>
>
> Andrei

But (one of) his point(s) is that the choice between type qualifier and storage class directly impacts his work. Why shouldn't a user express such a point?

On 12/28/14 4:33 PM, Walter Bright wrote:
> On 12/28/2014 12:04 PM, Peter Alexander wrote:
>> On Sunday, 28 December 2014 at 18:16:04 UTC, Andrei Alexandrescu wrote:
>>> Very little breakage I can think of. Ranges usually don't own their
>>> payload.
>>
>> I'm thinking more about higher order ranges, e.g. take, filter, cycle,
>> retro;
>> over a mutable range with ref front. Even if the underlying range
>> (e.g. an
>> array) has the inout, the higher order range will need the inout as
>> well, so
>> that it is propagated, no?
>
> inout is not transitive, so a ref on the container doesn't apply to a
> ref on the contents if there's another level of indirection in there.
>

I'm not sure what you mean by this, but inout as a type modifier is definitely transitive.

-Steve

On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
> Walter and I have been working on revamping DIP25, which focuses on
> tightening the screws of ref. This should then simplify DIP69
> significantly.
>
> Please comment: http://wiki.dlang.org/DIP25

ref int hun() inout { return b; }

This doesn't make sense. inout cannot cast to mutable.

Other than that, there is an issue with taking ref mutable parameters.

For example, you cannot implement an increment function:

ref int increment(ref int x) { return ++x;}

marking x as inout makes it effectively const during the body of the function, so such a function would be banned. I'm sure there are some of these in some code somewhere, I wouldn't be surprised if phobos had some.

I like the idea of inferring lifetime based on inout, and I think that connection is sound. But I don't like the idea of *requiring* inout to qualify ref returns of parameters. It's too restrictive.

-Steve

On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
> On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
>> Walter and I have been working on revamping DIP25, which focuses on
>> tightening the screws of ref. This should then simplify DIP69
>> significantly.
>>
>> Please comment: http://wiki.dlang.org/DIP25
>
> ref int hun() inout { return b; }
>
> This doesn't make sense. inout cannot cast to mutable.

Yah, the DIP should clarify that new behavior. Thanks. -- Andrei

On 12/29/14 2:58 AM, John Colvin wrote:
> On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote:
>> There is a rub though. Not only you're telling what we'd need to do to
>> be more successful, you're also telling us how to do it. Please don't.
>> We are not adding type qualifiers to D if we can avoid it, and
>> generally we want to achieve what we need to achieve with minimum
>> aggravation. Instead please focus on what you're trying to accomplish,
>> not on whether an artifact is a type qualifier or a storage class.
>> Thanks.
>>
>>
>> Andrei
>
> But (one of) his point(s) is that the choice between type qualifier and
> storage class directly impacts his work. Why shouldn't a user express
> such a point?

Making that point is fine so long as the costs are discussed alongside with the applicability to one particular task. -- Andrei

On 12/29/14 10:51 AM, Andrei Alexandrescu wrote:
> On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
>> On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
>>> Walter and I have been working on revamping DIP25, which focuses on
>>> tightening the screws of ref. This should then simplify DIP69
>>> significantly.
>>>
>>> Please comment: http://wiki.dlang.org/DIP25
>>
>> ref int hun() inout { return b; }
>>
>> This doesn't make sense. inout cannot cast to mutable.
>
> Yah, the DIP should clarify that new behavior. Thanks. -- Andrei

Huh? This behavior cannot be allowed.

If we can return mutable ref to a member when calling a member function on a const or immutable object, then we are in violation of const.

What is the point of the above? in such a function, what is typeof(this)?

Even if you can make up rules to make this sane, it's going to be boatloads more confusing than today's situation with inout.

-Steve

On Monday, 29 December 2014 at 04:13:18 UTC, Andrei Alexandrescu wrote:
> Walter's reasoning was: we have inout for propagating qualifiers from a parameter ("this" is also a parameter) to the output, so we can use it for propagating aliasing information as well.

Yay! I have been asking for it since scope threads started :)

I like the intention behind the DIP and I think idea itself is sound and fits naturally into existing language.

But this example confuses me:

@safe ref int wrongIdentity(ref int x) {
    return x; // ERROR! Cannot return a ref, please use "ref inout"
}

@safe ref int identity(ref inout int x) {
    return x; // fine
}

If existing meaning of is to be kept too second example should look like this:

@safe ref inout int identity(ref inout int x) {
    return x; // fine
}

otherwise it allows silent casting of const reference to mutable one!

On 12/29/14 8:09 AM, Steven Schveighoffer wrote:
> On 12/29/14 10:51 AM, Andrei Alexandrescu wrote:
>> On 12/29/14 6:07 AM, Steven Schveighoffer wrote:
>>> On 12/27/14 10:09 PM, Andrei Alexandrescu wrote:
>>>> Walter and I have been working on revamping DIP25, which focuses on
>>>> tightening the screws of ref. This should then simplify DIP69
>>>> significantly.
>>>>
>>>> Please comment: http://wiki.dlang.org/DIP25
>>>
>>> ref int hun() inout { return b; }
>>>
>>> This doesn't make sense. inout cannot cast to mutable.
>>
>> Yah, the DIP should clarify that new behavior. Thanks. -- Andrei
>
> Huh? This behavior cannot be allowed.
>
> If we can return mutable ref to a member when calling a member function
> on a const or immutable object, then we are in violation of const.
>
> What is the point of the above? in such a function, what is typeof(this)?
>
> Even if you can make up rules to make this sane, it's going to be
> boatloads more confusing than today's situation with inout.

I tend to agree. You seem to have shown that reusing inout for scope information becomes confusing. -- Andrei

On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu wrote:
> I tend to agree. You seem to have shown that reusing inout for scope information becomes confusing. -- Andrei

What is the problem with using inout exactly as it is now (== both for argument and return type) but defining it to propagate aliasing information as it is decribed in DIP25?

On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
> On 12/28/14 4:33 PM, Walter Bright wrote:
>> inout is not transitive, so a ref on the container doesn't apply to a
>> ref on the contents if there's another level of indirection in there.
> I'm not sure what you mean by this, but inout as a type modifier is definitely
> transitive.

As a type modifier, yes, it is transitive. As transferring lifetime to the return value, it is not.