Am 02.07.2017 um 08:39 schrieb H. S. Teoh via Digitalmars-d:
In your example, inout makes no sense at all. It should be written as:
const(char)[] foo(bool condition, const(char)[] chars)
because if it returns the argument, then it's const(char)[], and if it
returns an immutable global, then immutable(char)[] implicitly converts
to const(char)[]. Using inout doesn't make sense here because you
cannot assume that the return value is mutable if the parameter is
mutable -- the function may return immutable instead.
T
The idea is to be able to write: string result = foo(true, "bar");
There are arguments for both sides. On one hand, inout is already a very
specific hack in the language that often isn't applicable when it would
be handy, and a restriction here would probably not change much. On the
other hand it's always desirable to generalize a language feature as
much as possible, to get the maximum out of the complexity investment.
However, in this case it can be also argued that supporting this
specific case adds it's own complexity. The concept of const(inout(T))
definitely sounds like one of the harder ones to explain. So I'd
probably still opt for simplifying the conversion hierarchy.
