Tail-const is doable, but does not enjoy the implicit conversion that T[] has.
Without the implicit conversion, tail-const relies on unsafe casting, and that sucks. I agree with Andrei we need a language solution. The question really is not what the solution should do, that much is clear -- apply const to a subset of the members (either all references or members designated by some identifier). The question is, what does the syntax look like. That was the major stumbling block that flipped Walter's switch to "tail-const doesn't work". I think we should concentrate on structs and not class references, since class references have no syntax that separates the reference from the data. At least with structs, you can identify the parts to apply const to. We have a somewhat clunky solution in Rebindable for classes, so it would be nice to include them, but past experience has shown that to be a big rat hole. -Steve > >From: David Simcha <[email protected]> >To: Discuss the phobos library for D <[email protected]> >Sent: Thu, August 12, 2010 11:28:24 AM >Subject: Re: [phobos] is*Range + Qualified Types > > > > >On Thu, Aug 12, 2010 at 1:43 AM, Andrei Alexandrescu <[email protected]> wrote: > > >> 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)[]. >> >>That doesn't apply to most other ranges, which don't have an obvious >>"tail-const" version. >> >>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. >> 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 most 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. 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: 1. It's too hard to create non-trivial immutable data structures, especially without relying on unchecked casts during construction. 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. 3. inout is currently so bug-ridden it's not even funny. _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
