On Tue, 13 Dec 2011 06:07:49 -0500, kenji hara <[email protected]> wrote:
2011/12/13 Timon Gehr <[email protected]>:
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
