tail const

[Fawzi Mohamed]

On 1-dic-10, at 20:07, Michel Fortin wrote:

> On 2010-12-01 09:37:08 -0500, Michel Fortin  
> <michel.fortin at michelf.com> said:
>
>> On 2010-12-01 06:17:24 -0500, Jonathan M Davis  
>> <jmdavisProg at gmx.com> said:
>>>> I proposed the following a while ago. First allow the class  
>>>> reference
>>>> to (optionally) be made explicit:
>>>> C a;     // mutable reference to mutable class
>>>> C ref b; // mutable reference to mutable class
>>>> And now you can apply tail-const to it:
>>>> const(C)ref c;  // mutable reference to const class
>>>> const(C ref) d; // const reference to const class
>>>> const(C) e;     // const reference to const class
>>> The real issue is not syntax but getting it into the compiler.  
>>> Apparently, there
>>> are difficulties in implementing tail const in the compiler which  
>>> made Walter give
>>> up on it in the past. It should be doable, but Walter is totally  
>>> sick of the
>>> issue and doesn't want to put the time in to do it - he has plenty  
>>> on his plate
>>> as it is. So, if it's going to be done, someone else has to step  
>>> up to the plate
>>> and do it. And with the general lack of dmd developers, that  
>>> hasn't happened. No
>>> one thus far has had both the inclination and the time.
>> Well... I just took a quick look at the problem from inside the  
>> compiler. The issue is this: the compiler has a type hierarchy, and  
>> TypeClass is one type in it. There is no separate type for a class  
>> reference, it just uses TypeClass do designate a class reference,  
>> which means that if your TypeClass has the const or immutable  
>> modifier, so does your reference. So either we create a  
>> TypeClassRef to designate the reference, or we add additional flags  
>> to TypeClass for the reference's modifier; in either case many  
>> parts of the semantic analysis has to be revised to take this into  
>> account.
>
> Turns out it's there's a trick that makes it much simpler than I  
> expected. Patch coming soon. ;-)

great!

well as your are at it I would argue a bit more on the syntax.
In my opinion it is useful more useful to have a weak_const, (or @tail  
const , or *const, I don't care so much about the syntax, but I care  
about the concept), like I sketched in my post, and not just fix the  
class issue.
Indeed as I did try to argue it is useful to have an easy way to say  
"all my local stack memory might be modified, but not anything that it  
refers to" (thus weak const).
This is the maximum modifiability that one can allow to arguments to  
pure functions, so a very useful level of protection.
weak_const can be defined recursively:
weak_const T
is
- const(T) if T is a reference, a D has not rebinding of refs  
(otherwise it should protect only the object, not the rebinding of the  
ref).
- T if T is a basic type, function or delegate
- const(U)* if is(T U==U*)
- const(U)[] if is(T U==U[]) // this is a special case of the next
- WeakConst!(T) if (T==struct) where WeakConst!(T) is a structure like  
T, but where all its fields are weak_const (i.e. apply recursively  
weak_const to the content of the structure.

Indeed the recursion on the structure is the most complex thing, and  
might be an implementation challenge, but if doable it would be very  
nice.
Basically one has to set a flag for all things that are local, and  
would not be affected by the weak const.

I suppose that will probably considered too difficult to implement,  
but I wanted to propose it again because I find that it is the most  
clean solution conceptually.

Fawzi