<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-04-15 22:41 GMT+09:00 Andrei Alexandrescu via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 04/15/2016 06:50 AM, Kenji Hara via Digitalmars-d wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
You should recall the history of inout.<br>
<a href="http://wiki.dlang.org/DIP2" rel="noreferrer" target="_blank">http://wiki.dlang.org/DIP2</a><br>
<br>
At first, It has designed to temporarily squash mutable/const/immutable<br>
qualifiers on function argument inside function body. Therefore when<br>
inout qualifier appears in function return type, but doesn't on<br>
parameter types, we defined it an error.<br>
<br>
However, I concluded that we can remove the restriction. When an inout<br>
object arises from thin air, no one holds the qualifier of its real<br>
instance. It means, the returned inout object can be converted to<br>
arbitrary qualifiers without type system breaking.<br>
<br>
Two years ago I opened an enhancement issue:<br>
<a href="https://issues.dlang.org/show_bug.cgi?id=13006" rel="noreferrer" target="_blank">https://issues.dlang.org/show_bug.cgi?id=13006</a><br>
<br>
And posted a pull request.<br>
<a href="https://github.com/D-Programming-Language/dmd/pull/3740" rel="noreferrer" target="_blank">https://github.com/D-Programming-Language/dmd/pull/3740</a><br>
</blockquote>
<br></span>
I do recall the history. The enhancement is sensible in a frame of mind "we need to keep inout" but I'm looking at top level and thinking, crap we can put up with a little duplication if we get rid of inout. It's just a prime example of apparently simple idea gone bonkers.<br>
<br>
In all of my recent code I've avoided inout and didn't miss it one bit. There's no need for it - I replace it with one-liners that forward to template functions, which in turn deduce qualifiers and all is great.</blockquote><div><br></div><div>Didn't you use array.dup until now? It's a good example to handle qualifiers with inout.</div><div>It's not sensible at all, inout is already well-defined and has much power in D's type system.</div><div>Removing it is just a foolish idea.</div><div><br></div><div><div><div>If you worry the future of Phobos written in D, first you would need to think about @safe.</div><div>It's yet not well defined/implemented by compiler, and many Phobos code are marked as @trusted.</div><div>Does it has lower priority than complain to a small hack for the *current* inout limitation?</div></div></div><div><br></div><div>I just cannot agree your argument.</div><div><br></div><div>Kenji Hara</div></div></div></div>