Ironclad C++

[H. S. Teoh]

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!