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