any news on const/invariant?

[Walter Bright]

Bill Baxter wrote:
> Walter Bright wrote:
>> Every other storage class applies to the declaration, why should const 
>> be completely different?
> 
> We're talking here about methods, right?  And you're saying if we can do 
> this:
>     static int[] func() { }
> 
> then why shouldn't we be able to do this:
>     const int[] func() { } ??

And you can do that.

> The big difference is just that 'static int[]' as a return value makes 
> no sense, so there's only one way to read it, but "returns a const 
> int[]" is a logical way to mis-read the const version, especially for 
> C++ converts.

Ok, let's assume C++ is intuitive, consistent, and logical. Given:

const int *p;

what makes more logical, intuitive sense?

1) p is a non-constant pointer to const int?
2) p is a const pointer to a non-const int?
3) p is a const pointer to a const int?

I doubt you'll get a consistent answer from programmers who aren't 
already very used to the wacky C++ semantics.


> One workaround for people who find that confusing would be to reiterate 
> the protection:
> 
>     const public int[] func() {}
> 
> Which is not much more verbose than
> 
>     const(this) int[] func() { }

I doubt people will be confused by it for more than 5 minutes, and then 
it will make sense. I find the D version of const much more intuitive, 
from a logical, consistency point of view, than the C++ one.


> So I guess I can see people getting used to this.  So the question again 
> becomes why allow the at-the-end syntax too?  Isn't one syntax enough? 

It's a good question. Note that D allows both C-style and D-style array 
declarations. It makes it easier to convert C code over to D code.