any news on const/invariant?

[Bill Baxter]

Walter Bright wrote:
> 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.

Ok, but that seems to differ from your default position on other topics. 
  Usually I see you saying we should do things to not confuse C++ 
coders.  "If it looks like C++ it should behave like C++" is the 
impression I've gotten in the past.   But maybe you're gaining enough 
confidence in D these days that you're not as concerned about that any 
more. :-)

... So can we talk about the fall-through default in switch statements 
again?  :-)

>> 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. 

And the only commentary I've heard on that feature from D users has been 
negative.  There could be a "silent majority" in favor of it, but I 
doubt it.

> It makes it easier to convert C code over to D code.

So you're making this at-the-end-const special case for no other reason 
than to make it easier to convert C++ code?  As someone who converted a 
15K-line C++ library, I don't think that this one thing will help much. 
  At least not for someone translating manually.  Perhaps it would help 
an automatic translator.  But I doubt it.  "Move const-after-parameters 
to const-before-declaration" would be a relatively straightforward 
conversion rule to implement.  Much easier than the 
"convert-struct-with-inheritance-to-something-else" rule. :-)

--bb