I wish all qualifiers were revisited with an eye for simplification

[Steven Schveighoffer]

On 8/14/20 9:45 AM, Andrei Alexandrescu wrote:

> Well for what it's worth I have a simple question: how can I assess in 
> druntime if a type T is copyable? I add the informal requirement that 
> it's a simple query so it should be served with a proportionally simple 
> answer.
> 
> My initial take:
> 
> static if (is(typeof((T x) { T y = x; }))) { ... }
> 
> i.e. a lambda can be created that takes a T and creates a copy of it. 
> Beautiful.
> 
> This test, however, passes for inout types. And inout types cannot be 
> considered really copyable, because they cannot be used in many places 
> where one would expect to use a copyable type. To wit, a variety of 
> unittests will fail (such as structs with copyable members), all 
> protesting to the attempt of classifying inout types as copyable.

inout types aren't any less copyable than const or immutable types.

> 
> Second attempt:
> 
> static if (is(typeof((T x) { T y = x; })) && !is(T == inout U, U) { ... }
> 
> So a type is copyable as before, just let's special case inout for 
> exclusion.

This seems silly, if it's copyable it's copyable. The unrestricted test 
should be valid.

> 
> This already gets my diaper in a bunch because I need to special case a 
> type of which utility I already am suspicious. And it's not only here - 
> it's many, many similar places.
> 
> Also, this also does NOT work because inout(const(int)) passes the test. 
> This could probably be classified as a bug in the language or its compiler.
> 
> So now I'm looking at things like importing "core.lifetime : emplace" 
> and see if that compiles. Because the very complex implementation of 
> emplace uses a complex mechanism to handle inout.
> 
> I could be convinced that this awful complexity is justified given the 
> choices made in the definition of this or that, but it would be more 
> difficult to convince ourselves this is good programming language 
> design. Simple questions should have simple answers.

Is there a specific example? I suspect we are going to get into one of 
the foolish restrictions of inout -- can't be struct members or can't be 
returned if you don't have inout parameters.

The answer is still -- fix inout so it's not so foolish.

-Steve