Why do "const inout" and "const inout shared" exist?
Sönke Ludwig via Digitalmars-d
digitalmars-d at puremagic.com
Sun Jul 2 01:12:21 PDT 2017
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.
More information about the Digitalmars-d
mailing list