[phobos] is*Range + Qualified Types

[Steve Schveighoffer]

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>
>To: Discuss the phobos library for D <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> 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.