On Tuesday, 6 August 2013 at 15:13:18 UTC, Kagamin wrote:
> inout already has proper scoping: data external to the function shouldn't be qualified as inout, it just should be checked.

In shown examples, 2 function signatures are involved. If you don't understand where the ambiguity lies, I suggest you step back and reconsider the situation.

On 08/06/2013 05:13 PM, Kagamin wrote:
> On Tuesday, 6 August 2013 at 02:11:54 UTC, Timon Gehr wrote:
>> I thought I had demonstrated that it buys you more. It resolves the
>> problem that scoping is ambiguous and that there can be only one
>> 'inout' substitution per function application.
>
> It may look ambiguous to someone who doesn't know, how the feature
> works, because it's implicit, which, again, is a tradeoff. Subjective
> ambiguity should be solvable with better docs, learning resources and
> tutorials.
> ...

???

Nothing subjective about this! Even DMD does not know how the feature works in this case.

On Tuesday, 6 August 2013 at 16:55:43 UTC, deadalnix wrote:
> On Tuesday, 6 August 2013 at 15:13:18 UTC, Kagamin wrote:
>> inout already has proper scoping: data external to the function shouldn't be qualified as inout, it just should be checked.
>
> In shown examples, 2 function signatures are involved. If you don't understand where the ambiguity lies, I suggest you step back and reconsider the situation.

Semantics of inout doesn't depend on the number of functions. What is ambiguous in the given description?

On Tuesday, 6 August 2013 at 19:26:09 UTC, Timon Gehr wrote:
> Nothing subjective about this! Even DMD does not know how the feature works in this case.

It's just an unintended implementation error for a case which was not explicitly considered. Should be fixable.

On Friday, 9 August 2013 at 14:47:23 UTC, Kagamin wrote:
> On Tuesday, 6 August 2013 at 16:55:43 UTC, deadalnix wrote:
>> On Tuesday, 6 August 2013 at 15:13:18 UTC, Kagamin wrote:
>>> inout already has proper scoping: data external to the function shouldn't be qualified as inout, it just should be checked.
>>
>> In shown examples, 2 function signatures are involved. If you don't understand where the ambiguity lies, I suggest you step back and reconsider the situation.
>
> Semantics of inout doesn't depend on the number of functions. What is ambiguous in the given description?

It is ambiguous if the inout of the function passed as parameter stand for the function passed as parameter or the function you pass the parameter to.

On Fri, Aug 09, 2013 at 07:00:49PM +0200, deadalnix wrote:
> On Friday, 9 August 2013 at 14:47:23 UTC, Kagamin wrote:
> >On Tuesday, 6 August 2013 at 16:55:43 UTC, deadalnix wrote:
> >>On Tuesday, 6 August 2013 at 15:13:18 UTC, Kagamin wrote:
> >>>inout already has proper scoping: data external to the function shouldn't be qualified as inout, it just should be checked.
> >>
> >>In shown examples, 2 function signatures are involved. If you don't understand where the ambiguity lies, I suggest you step back and reconsider the situation.
> >
> >Semantics of inout doesn't depend on the number of functions. What is ambiguous in the given description?
> 
> It is ambiguous if the inout of the function passed as parameter stand for the function passed as parameter or the function you pass the parameter to.

The meaning of inout basically means that whatever the type qualifiers are on the parameters, like const, immutable, etc., are automatically propagated to the return type. For example:

	T func(inout T t) inout {
		...
		return t;
	}

	T t;
	const(T) ct;
	immutable(T) it;

	func(t);	// return type is T
	func(ct);	// return type is const(T)
	func(it);	// return type is immutable(T)

One problem area with inout is that when delegates are involved, the meaning becomes unclear:

	auto func(inout int delegate(inout x) dg, U parm) inout {
		// What's the return type of the function?
		return dg(parm);
	}

Does it mean that dg is an inout parameter, or that dg is a normal parameter, that happens to be an inout delegate of *its* own parameters?

Also, is this valid?

	T func(inout T x, inout T y) inout {
		return (someCondition) ? x : y;
	}

	T t;
	const(T) ct;
	immutable(T) it;

	auto z = func(t, ct);	// is this valid? If so, what's the return type?
	auto w = func(ct, it);	// ditto

I'm not 100% sure about this.


T

-- 
That's not a bug; that's a feature!

On Friday, 9 August 2013 at 17:00:53 UTC, deadalnix wrote:
> It is ambiguous if the inout of the function passed as parameter stand for the function passed as parameter or the function you pass the parameter to.

See my explanation, how inout works and why your example ignores semantics of inout:
http://forum.dlang.org/post/jenapjffdszqqclyxhgc@forum.dlang.org

On Friday, 16 August 2013 at 05:48:12 UTC, Kagamin wrote:
> On Friday, 9 August 2013 at 17:00:53 UTC, deadalnix wrote:
>> It is ambiguous if the inout of the function passed as parameter stand for the function passed as parameter or the function you pass the parameter to.
>
> See my explanation, how inout works and why your example ignores semantics of inout:
> http://forum.dlang.org/post/jenapjffdszqqclyxhgc@forum.dlang.org

Dude I've read that. Your definition isn't helping in any way to resolve the ambiguity we are talking about here, and so the only reasonable assumption I can make at this point is that you didn't understood how the presented cases were ambiguous.

Right now you are losing your time and ours, by explaining us something we already know.