<br><br><div class="gmail_quote">On Thu, Aug 12, 2010 at 1:43 AM, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:andrei@erdani.com">andrei@erdani.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br></div>
I think the main argument is that currently most of std.algorithm doesn't work with const arrays, which have a simple "tail-const" version. const(T[]) is implicitly convertible to const(T)[].<br>
<br>
That doesn't apply to most other ranges, which don't have an obvious "tail-const" version.<br>
<br>
David, I think we need to think through a bit more before proceeding. The way I assume you want to proceed is to essentially add a special function signature for each algorithm and have it forward to the peeled version. Perhaps we could look at a simpler solution, e.g. one that would involve a language change.<br>
</blockquote><div><br>Fair enough. If you think this might be better solved at the language level, that's a worthwhile discussion to have. I do believe, though, that <b>most</b> ranges besides T[] do have an obvious "tail-const" version, since in practice most ranges are structs that have the iteration state stored inline and only use indirection to store the payload, if anywhere.<br>
<br>At any rate, I think this is a must-solve problem. Despite its theoretical beauty, I find D's const/immutable system to be utterly useless (and I've made a serious attempt to use it in a real multithreaded program) for all but the simplest cases in practice, for three reasons:<br>
<br>1. It's too hard to create non-trivial immutable data structures, especially without relying on unchecked casts during construction.<br><br>2. So many things in Phobos (even things as simple as std.math.pow() before I recently fixed it) behave incorrectly when given const/immutable data. This also applies to other libraries I use, including ones that I'm the main author of, so I'm just as guilty of it as anyone. Given that noone, including me, seems to be able to get this right in generic code, perhaps this does point to the need for a language-level solution.<br>
<br>3. inout is currently so bug-ridden it's not even funny.</div></div>