tail const

[Andrei Alexandrescu]

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.

The burden of defining @tail const/immutable/inout functions in addition 
to non- at tail const/immutable/inout functions (sometimes the distinction 
would need to be made!) is just too high. I think we need to work out 
solutions within the existing language.


Andrei