relax inout rules?

[Steven Schveighoffer]

On Tue, 13 Dec 2011 06:07:49 -0500, kenji hara <k.hara.pg at gmail.com> wrote:

> 2011/12/13 Timon Gehr <timon.gehr at gmx.ch>:
>> On 12/13/2011 09:41 AM, kenji hara wrote:
> [snip]
>>>
>>> Against an inout function that does not return inout type:
>>> - the number of inout parameters should be 2 more?
>>
>> If we required that, then IFTI would also have to replace inout with  
>> const
>> in case there is only one of them. That potentially introduces
>> counter-intuitive behaviour.
>
> Maybe it is an enhancement filed as 6809.

I think if we loosen the restriction of inout so that it can be only one  
one parameter, then it becomes simply a new type of immutable.  This makes  
moot that enhancement request I filed.  I think you have suggested similar  
things in the past and I argued against it (I'm sorry for changing my  
mind!)

The idea that inout simply resolves to something, and then the call falls  
under normal rules is really attractive.

I even thought of another idea: If inout is solely on return value, then  
there is no way to resolve what inout should be matched to.  But what if  
it simply becomes polyconst (can bind to any flavor of const)?  Because  
there are no inout parameters, and global inout variables are illegal, it  
can be deduced that the value must be unique.

I had previously suggested that only having inout on the return type  
should be illegal, so this would supersede that.

>>> - at least one parameter should have 'out' or 'ref' storage class as a
>>> *return parameter*?
>>
>> Not necessarily.
>>
>>> But I'm not sure these restrictions are necessarily required.
>>
>> I think we should indeed drop the restrictions, because they complicate  
>> the
>> language for little gain.
>
> Indeed.

I agree with Timon here.

-Steve