tail const

[Steven Schveighoffer]

On Fri, 03 Dec 2010 19:06:36 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 12/3/10 5:17 PM, Steven Schveighoffer wrote:
>> On Thu, 02 Dec 2010 17:02:42 -0500, Michel Fortin
>> <michel.fortin at michelf.com> wrote:
>>
>>> On 2010-12-02 16:14:58 -0500, "Steven Schveighoffer"
>>> <schveiguy at yahoo.com> said:
>>>
>>>> On Thu, 02 Dec 2010 07:09:27 -0500, Michel Fortin
>>>> <michel.fortin at michelf.com> wrote:
>>>>> My only concern with the "const(Object)ref" syntax is that we're
>>>>> reusing 'ref' to denote an object reference with different
>>>>> properties (rebindable, nullable) than what 'ref' currently stands
>>>>> for. But it remains the best syntax I've seen so far.
>>>> Where it would be beneficial is in mimicking the tail-const
>>>> properties of arrays in generic ranges.
>>>> I have a container C, which defines a range over its elements R.
>>>> const(R) is not a usable range, because popFront cannot be const. So
>>>> now I need to define constR, which is identical to R, except the
>>>> front() function returns a const element.
>>>> So now, I need the same for immutable.
>>>> And now I need to triplicate all my functions which accept the
>>>> ranges, or return them.
>>>> And I can't use inout(R) as a return value for ranges.
>>>> If you can solve the general problem, and not just the class
>>>> tail-const, it would be hugely beneficial.
>>>> My thought was that a modifier on const itself could be stored in the
>>>> TypeInfo_Const as a boolean (tail or not), and the equivalent done in
>>>> dmd source itself.
>>>
>>> I'm not sure I get the problem. Can you show me in code?
>>
>> Here is an example range from dcollections (well, at least the pertinant
>> part), for a linked list:
> [snip analysis]
>> @tail inout(Range) opSlice() inout
>> {
>>   ...
>> }
>
> I was about to post a similar analysis, but my suggested conclusion is  
> very different: in my humble opinion, we must make-do without tail  
> const. We can't afford to inflict such complexity on our users.

BTW, even though I conceed that my ideas are too complex to be worth  
using, I don't agree we must "make-do" without tail-const.  We just need  
to find a different way to solve the problem.  Let's talk about how we  
could add some sort of custom implicit casting to the type-system.  And  
actually, we need implicit lvalue casting (because all member functions  
have ref this).

-Steve