It turns out it's quite hard to have @safe pure nothrow functions. Oh, and const.

[Timon Gehr via Digitalmars-d]

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.