const(Object)ref is here!

[Graham St Jack]

On 07/12/10 05:51, Steven Schveighoffer wrote:
> On Mon, 06 Dec 2010 14:04:43 -0500, Jonathan M Davis 
> <jmdavisProg at gmx.com> wrote:
>
>> On Monday, December 06, 2010 07:37:27 Steven Schveighoffer wrote:
>
>>> It should be relatively painless.  Just change the signatures of the 
>>> base
>>> functions, and fix any compile errors.
>>
>> And watch all the code break... I'll definitely welcome the change 
>> (it's probably
>> the first bug that I voted on in bugzilla), but there will be tons of 
>> code broken
>> by it, since you just _know_ that a lot of user code doesn't bother 
>> to make
>> toString() and its friends const. It's still a change that needs to 
>> be made
>> though. Being unable to properly compare const and immutable objects is
>> crippling. Of course, it would be more of an issue if it were easier 
>> to actually
>> create immutable objects which are classes rather than strcuts, but 
>> that's a
>> separate issue.
>
> Yes, one of the issues is that const has a viral effect.  If you 
> ignore const, none of your functions are const.  So if you use 
> functions inside opEquals, those have to be marked as const, and so on.
>
> But there are very few circumstances where opEquals needs to be marked 
> as mutable.  If that is the case, there is something broken with your 
> code (and you should fix it) or there's something wrong with code you 
> use (and you'll have to insert casts to deal with it for now).  In a 
> very small number of circumstances, non-const opEquals can be 
> beneficial (such as caching data that is expensive to calculate).  We 
> need to find another way to deal with that (I suggest having logical 
> const, but that's not a popular idea with Walter :).  But it shouldn't 
> detract from the requirements.  You can always circumvent if you need 
> special cases.  I'd rather start from a solid const-supporting 
> position and add holes where they make sense then start from a base 
> that is full of holes and try to patch them slowly.
>
> In many cases affixing const to your code is not just a simple 'slap a 
> const on here'.  It can involve careful thought and possibly redesign.
>
> But without these changes, const is very useless, the standard library 
> needs to eat its own dogfood if we want to peddle it to others.
>
> -Steve
Vote++

-- 
Graham St Jack