std.xml should just go

[Steven Schveighoffer]

On Fri, 04 Feb 2011 13:49:42 -0500, so <so at so.do> wrote:


> Now, what i mean with this:
>
> ---
> struct A {
> 	B whatever;
> 	bool opEquals(A a) {
> 		return whatever == a.whatever;  // just comparision, this function is  
> const
> 	}
> 	bool anything(A a) {
> 		whatever = 2; // here i have an assignment, this function is not const
> 		return whatever;
> 	}
> }
> ---
>
> It doesn't matter what signature you use for the function, compiler is  
> aware and will output an error when you do the opposite of the  
> signature. If this is the case, why do we need that signature?
> Its presence just makes things complicated and with actually no reason.

Actually, there are two reasons.

First, it's due to the compilation model of D.  Without the signature to  
convey the information, the compiler cannot make any guarantees.  It is  
legal to declare simply a function signature without the relevant source,  
in order to link against the function.  This means, the compiler does not  
have access to the source, so if it doesn't have access to the source, how  
does it know that the function is const or not?

Second, it has to do with the desires of the developer who's writing the  
function.

Let's say you have your code, and the opEquals is treated as const due to  
the implicit detection of the compiler.  Now, you realize your code that  
compares B types is really slow, so you want to do some sort of caching of  
the data:

struct A
{
    private B whatever; // changed to private for illustration purposes
    private md5 previousCompare;
    private bool previousCompareResult;

    bool opEquals(A a)
    {
       md5 ah = getMd5sum(a);
       if(ah != previousCompare)
       {
          previousCompare = ah;
          previousCompareResult = (whatever == a.whatever);
       }
       return previousCompareResult;
    }
...
}

So what does the compiler do?  Well, not only would this function now  
silently not be const, it silently un-consts all functions that call it.

The point is, many times, people want the compiler to tell them "hey, wait  
a minute, you marked this as const, but you're trying to do non-const  
things!"  As it turns out, it's really useful to know "this function is  
not going to change your object/struct."  logically, you can make a lot of  
assumptions based on that.  If the compiler doesn't help you enforce that,  
then stuff like the above creeps into the code, and your const expectation  
is broken.

What's somewhat unfortunate is that once you mark something as const, you  
have to mark all sorts of other things as const.  So for example, B's  
opEquals must also be const.  However, if you properly mark items as const  
when they really are const, this should already be the case.

The statement that "you don't need to use const if you don't want to" is  
really weak.  If you use D libraries, you will undoubtedly have to use  
const (once const is sane and libraries start using it).   But using it is  
not "pointless" and does add value.

-Steve