All right, all right! Interim decision regarding qualified Object methods

[Steven Schveighoffer]

On Thu, 12 Jul 2012 21:30:36 -0400, Mehrdad <wfunction at hotmail.com> wrote:

> On Friday, 13 July 2012 at 01:22:59 UTC, Jonathan M Davis wrote:
>> There's big difference between a library and a the language itself.
>
> Surely that's a non sequitur... Aren't we modifying druntime here?
> What part of this has to do with the _language_? Isn't druntime a  
> library?
>
> Also, why can't you tell the user, "it's open-source! If it doesn't suit  
> your needs, go modify it! Removing const is trivial!"
> What makes it so easy to say that about every library /except/ druntime?

First, Object (and the functions in object_.d) is treated specially by the  
compiler.  For exammple, object.opEquals worked on const objects, even  
though the function parameters were not const.

Second, If you change druntime, you might as well be hacking the  
compiler.  Every *single* library depends on druntime, including phobos.   
Are you going to change all them too?

It's like saying it's as easy to prune a tree trunk as it is to prune a  
branch.

> 1. Again, see above -- Object is also in a library. Why doesn't the  
> reasoning apply there? It's trivial to remove const from the library and  
> recompile it -- _FAR_ easier than it is to modify any arbitrary library.  
> (Speaking of which, thanks for making it so easy to modify & recompile  
> druntime!)

No, it's not.  Everything depends on druntime.  If you think it was so  
easy, look at the date of this bug report, which all the top dogs agreed  
with: http://d.puremagic.com/issues/show_bug.cgi?id=1824

> 2. Isn't it kinda /trivial/ to avoid opEquals? Just don't use it. Make  
> up your own method. What's wrong with this?

Yes, it is.  There isn't anything wrong with that, and it has been  
suggested -- if you want non-const opEquals, write your own method.

But I think we are past that point, in all likelihood, opEquals is going  
away from Object.

-Steve