<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-04-15 14:38 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 12:23 AM, Jonathan M Davis via Digitalmars-d wrote:<br>
</span><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 Thursday, April 14, 2016 23:10:12 Andrei Alexandrescu via Digitalmars-d<br>
wrote:<br>
</span><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">
Consider:<br>
<br>
<a href="https://github.com/D-Programming-Language/phobos/blob/master/std/range/primi" rel="noreferrer" target="_blank">https://github.com/D-Programming-Language/phobos/blob/master/std/range/primi</a><br>
tives.d#L152<br>
<br><span class="">
There is no explanation to it in the source code, and the line blames to<br>
<a href="https://github.com/D-Programming-Language/phobos/pull/2661" rel="noreferrer" target="_blank">https://github.com/D-Programming-Language/phobos/pull/2661</a> (irrelevant).<br>
<br>
Commenting it out yields a number of unittest compilation errors,<br>
neither informative about the root of the problem and indicative as to<br>
how the parameter solves it.<br>
<br>
There are two issues here:<br>
<br>
1. Once a problem/solution pair of this degree of subtlety crops up, we<br>
need to convince ourselves that that's sensible. If we deem it not so,<br>
we look into improving the language to make the problem disappear.<br>
<br>
2. There needs to be documentation for people working on the standard<br>
library so they don't need to waste time on their own discovery process.<br>
<br>
We want Phobos to be beautiful, a prime example of good D code.<br>
Admittedly, it also needs to be very general and efficient, which<br>
sometimes gets in the way. But we cannot afford an accumulation of mad<br>
tricks to obscure the large design.<br>
</span></blockquote>
<br><span class="">
IIRC, the problem has to do with ranges of inout elements working correctly,<br>
which gets really funky, because inout is a temporary thing and not a<br>
full-on type constructor/qualifier. I believe that Kenji is the one that<br>
implemented the fix, and I think that he explained it in the newsgroup at<br>
some point. Certainly, there have been a few times that it's come up in<br>
D.Learn when folks ask what the heck it is, so there should be a few posts<br>
floating around with an explanation. This is the only useful post that I<br>
could find in a quick search though:<br>
<br>
<a href="http://forum.dlang.org/post/mh68p8$2p56$1@digitalmars.com" rel="noreferrer" target="_blank">http://forum.dlang.org/post/mh68p8$2p56$1@digitalmars.com</a><br>
<br>
inout attempts to solve a very real problem, but it does seem to be<br>
surprisingly hard to understand and use prooperly even though it's<br>
theoretically simple. And this bit with ranges is a quirk that I think very<br>
few people understand and remember. I usually forget exactly what it does<br>
when it comes up and have to try and dig through the newsgroup archives for<br>
a previous discussion on it.<br>
<br>
- Jonathan M Davis<br>
</span></blockquote>
<br>
I think we should deprecate inout. For real. It costs way too much for what it does. For all I can tell most of D's proponents don't know how it works. -- Andrei<br></blockquote><div><br></div><div><br></div><div>You should recall the history of inout.</div><div><a href="http://wiki.dlang.org/DIP2">http://wiki.dlang.org/DIP2</a><br></div><div><br></div><div>At first, It has designed to temporarily squash mutable/const/immutable qualifiers on function argument inside function body. Therefore when inout qualifier appears in function return type, but doesn't on parameter types, we defined it an error.</div><div><br></div><div>However, I concluded that we can remove the restriction. When an inout object arises from thin air, no one holds the qualifier of its real instance. It means, the returned inout object can be converted to arbitrary qualifiers without type system breaking.</div><div><br></div><div>Two years ago I opened an enhancement issue:</div><div><a href="https://issues.dlang.org/show_bug.cgi?id=13006">https://issues.dlang.org/show_bug.cgi?id=13006</a><br></div><div><br></div><div>And posted a pull request.</div><div><a href="https://github.com/D-Programming-Language/dmd/pull/3740">https://github.com/D-Programming-Language/dmd/pull/3740</a><br></div><div><br></div><div>Kenji Hara</div></div></div></div>