I wish all qualifiers were revisited with an eye for simplification

[Timon Gehr]

On 14.08.20 15:45, Andrei Alexandrescu wrote:
> On 8/4/20 12:57 PM, Timon Gehr wrote:
>>> * Every time "inout" comes within a radius of a mile of what I'm 
>>> doing, it starts to stink like a skunk. I wish I could get a 
>>> restraining order. I can't instantiate "inout" variables, so writing 
>>> any tests or constraints becomes an advanced matter of defining 
>>> functions and crap.
>>
>> I have never understood the `(inout int){ T.init; }` idiom. Just use 
>> `(T value){ value; }`.
>>
>>> I get frustrated, I protest to this forum, and immediately a cabal is 
>>> raised under Timon's leadership. The cabal convinces me that inout is 
>>> actually great and that I'm an idiot. I do get convinced, which is 
>>> more of a proof that Timon is very good, than a testament to the 
>>> conviviality of inout. Then I leave and get back to my code, and it 
>>> stinks of inout again. And I hate it and myself for having to deal 
>>> with it.
>>> ...
>>
>> I am sure you are sincere, but I still think this is a 
>> misrepresentation. I don't think I ever claimed that `inout` is great. 
>> I merely understand what `inout` is supposed to be, but it comes way 
>> short. See all of the issues I have opened that show that type 
>> checking for `inout` is broken. When I tried to document inout 
>> properly in 2018 I found multiple new type system holes, I think they 
>> are open to this day.
> 
> 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.
> ...

Those are protesting to the attempt of using `inout` types as member 
variables, not to the attempt of classifying them as copyable. The 
question is whether we really want types that can't be used as fields, 
and I think no, we don't want that. (But all of those weird limitations 
would not exist if `inout` was designed right!)

> ...
> 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.
> ...

It most definitely is.

> 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.

The complexity is not justified, it is not good programming language 
design and I never claimed otherwise. Good programming language features 
are orthogonal to each other.

> Simple questions should have simple answers.

If the above implementation of isCopyable is not the one you want, 
something else is off.