<div dir="ltr"><div dir="ltr">On Fri, Aug 14, 2020 at 11:50 PM Andrei Alexandrescu via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/4/20 12:57 PM, Timon Gehr wrote:<br>
>> * Every time "inout" comes within a radius of a mile of what I'm <br>
>> doing, it starts to stink like a skunk. I wish I could get a <br>
>> restraining order. I can't instantiate "inout" variables, so writing <br>
>> any tests or constraints becomes an advanced matter of defining <br>
>> functions and crap.<br>
> <br>
> I have never understood the `(inout int){ T.init; }` idiom. Just use `(T <br>
> value){ value; }`.<br>
> <br>
>> I get frustrated, I protest to this forum, and immediately a cabal is <br>
>> raised under Timon's leadership. The cabal convinces me that inout is <br>
>> actually great and that I'm an idiot. I do get convinced, which is <br>
>> more of a proof that Timon is very good, than a testament to the <br>
>> conviviality of inout. Then I leave and get back to my code, and it <br>
>> stinks of inout again. And I hate it and myself for having to deal <br>
>> with it.<br>
>> ...<br>
> <br>
> I am sure you are sincere, but I still think this is a <br>
> misrepresentation. I don't think I ever claimed that `inout` is great. I <br>
> merely understand what `inout` is supposed to be, but it comes way <br>
> short. See all of the issues I have opened that show that type checking <br>
> for `inout` is broken. When I tried to document inout properly in 2018 I <br>
> found multiple new type system holes, I think they are open to this day.<br>
<br>
Well for what it's worth I have a simple question: how can I assess in <br>
druntime if a type T is copyable? I add the informal requirement that <br>
it's a simple query so it should be served with a proportionally simple <br>
answer.<br>
<br>
My initial take:<br>
<br>
static if (is(typeof((T x) { T y = x; }))) { ... }<br>
<br>
i.e. a lambda can be created that takes a T and creates a copy of it. <br>
Beautiful.<br>
<br>
This test, however, passes for inout types. And inout types cannot be <br>
considered really copyable, because they cannot be used in many places <br>
where one would expect to use a copyable type. To wit, a variety of <br>
unittests will fail (such as structs with copyable members), all <br>
protesting to the attempt of classifying inout types as copyable.<br>
<br>
Second attempt:<br>
<br>
static if (is(typeof((T x) { T y = x; })) && !is(T == inout U, U) { ... }<br>
<br>
So a type is copyable as before, just let's special case inout for <br>
exclusion.<br>
<br>
This already gets my diaper in a bunch because I need to special case a <br>
type of which utility I already am suspicious. And it's not only here - <br>
it's many, many similar places.<br>
<br>
Also, this also does NOT work because inout(const(int)) passes the test. <br>
This could probably be classified as a bug in the language or its compiler.<br>
<br>
So now I'm looking at things like importing "core.lifetime : emplace" <br>
and see if that compiles. Because the very complex implementation of <br>
emplace uses a complex mechanism to handle inout.<br>
<br>
I could be convinced that this awful complexity is justified given the <br>
choices made in the definition of this or that, but it would be more <br>
difficult to convince ourselves this is good programming language <br>
design. Simple questions should have simple answers.<br></blockquote><div><br></div><div>I'm delighted by this post. Keep talking this way, and we have a chance to make the kind of progress we've been waiting for!</div><div><br></div><div>If you're looking into emplace (and friends) you should be familiar with Suleyman's move constructor work-in-progress. I am convinced that's the only reasonable path forwards on that front.</div></div></div>