On 09/13/2014 09:58 PM, Kagamin wrote:
On Saturday, 13 September 2014 at 18:36:53 UTC, Timon Gehr wrote:
On 09/13/2014 07:48 PM, Kagamin wrote:
On Saturday, 13 September 2014 at 16:51:09 UTC, Timon Gehr wrote:
s.bar((int* p){ ++*p; });
Huh? inout is for functions, which don't modify their arguments.
With Jakob's code working, this would not be warranted.
Huh? See rationale in https://issues.dlang.org/show_bug.cgi?id=1961
...
All the examples there keep their non-modification guarantees.
Modifications to inout parameters are visible at the call site.
If inout should still guarantee non-modification in the future, then
nested inout functions will need to introduce their own inout context
(i.e. the inout qualifier of the nested function should be
incompatible with the inout qualifier of the enclosing function.) I
assume this is a major PITA to implement in DMD, and it also leads to
growing pains that are hard to counter without enhancing the syntax,
hence the current semantics.
I think, it can be more or less simple without syntax enhancements, see
the description of how it can be implemented.
Even without going into details, it is easy to appreciate the fact that
erasing type information while enforcing type safety invariably tends to
lead to pain some way down the road. E.g. the inout qualifier of the
enclosing function should still be fully compatible with _itself_ even
when data is accessed and modified from the nested function.
