[phobos] is*Range + Qualified Types

[Andrei Alexandrescu]

Exactly. I vividly remember our (Bartosz, Walter, me) discussion that 
settled this - the competing approach was to define distinct syntactic 
constructs for "head const", "tail const", and "all const".

Back then we decided that three flavors of const (and three of 
immutable) would be unacceptable as too complex. We decided that tail 
const for arrays was already possible syntactically (const(T[]) vs. 
const(T)[]) and that we'll leave libraries to define their own 
const(Artifact!T) vs. Artifact!(const T) if they so need.

I think it's okay to change the compiler to automatically convert 
const(T[]) to const(T)[] upon any function call. The function's 
parameter is private anyway. There's hardly any loss of information - I 
doubt a function could actually be interested in that distinction.


Andrei

David Simcha wrote:
> Ok, now I get why using Unqual to get tail const wouldn't work.  My 
> silly oversight:
> 
> // The following doesn't work, though the natural tail
> // const for const(Cycle!(int[])) is Cycle!(const(int)[]),
> // because Unqual!(const(Cycle!(int[]))) == Cycle!(int[]).
> import std.range, std.traits;
> 
> void main() {
>     const myRange = cycle([1,2,3,4]);
>     pragma(msg, typeof(myRange));
> 
>     Unqual!(typeof(myRange)) myRangeMutable = myRange;
>     pragma(msg, typeof(myRange));
> }
> 
> 
> On Thu, Aug 12, 2010 at 11:37 AM, Steve Schveighoffer 
> <schveiguy at yahoo.com <mailto:schveiguy at yahoo.com>> wrote:
> 
>     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 <dsimcha at gmail.com <mailto:dsimcha at gmail.com>>
>      >To: Discuss the phobos library for D <phobos at puremagic.com
>     <mailto:phobos at puremagic.com>>
>      >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
>     <andrei at erdani.com <mailto:andrei at erdani.com>> 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
>     phobos at puremagic.com <mailto:phobos at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos