preparing for const, final, and invariant

[Dave]

Bill Baxter wrote:
> Jarrett Billingsley wrote:
>> "Charlie" <charlie.fats at gmail.com> wrote in message 
>> news:46649DD9.1010801 at gmail.com...
>>> I'm appalled, both that this is pretty much assured to be in D , and 
>>> that the community seems to be behind it.  I thought that the reason 
>>> Walter didn't want const was because of its added complexity , so 
>>> instead he introduces _3_ new keywords ?  Does no one else feel like 
>>> this is using a machine gun to kill a fly ?
>>>
>>> I understand the need for immutable data when writing libraries, but 
>>> 'scope const final MyClass myInstance' ?!?  Theres got to be a better 
>>> way.
>>>
>>> I know this sounds over-dramatic, but if this is the direction D is 
>>> headed, then count me out.  I loved D because if its elegant and 
>>> powerful simplicity, I think D has strayed way to far from its 
>>> original goal.
>>>
>>> If anyone feels like _this_ implementation for const ( not the 
>>> usefulness of const mind you ) is not for D, then please speak up or 
>>> we all might end up losing our favorite language.
>>>
>>
>> I was beginning to think I was the only one.  It doesn't seem any 
>> easier than the C++ style const-ness at all.  If anything it's more 
>> complex. Instead of "here a const, there a const, everywhere a const * 
>> const" it seems like it'll be "here a const, there a final, everywhere 
>> an invariant scope int[new]" :P 
> 
> I think we should wait and see how it comes out.  Of course expressing 
> your doubts and misgivings is a good thing too, but, yeh, let's try not 
> to be over-dramatic.  Naturally the discussion here tends to revolve 
> around the cases that aren't obvious or straightforward, because the 
> obvious, easy cases need no discussion.  So it's natural that it ends up 
> sounding like "everywhere an invariant scope int[new]", but I suspect in 
> typical code such things will be uncommon.
> 

Recalling the resistance that Walter originally had to adding const (the 'loose' semantics of C++ 
const and the concern about "littering" D code w/ const), I too think it will be wise to see what 
Walter has come up with. I'm pretty confident it will be both better and less onerous than C++ const 
for a majority of situations given the quality of design (of D) in other areas.

> I'm not sure about this int[*] thing though. That will probably require 
> a lot of changes whether int[*] ends up meaning resizeable or not.  But 
> come on, you have to admit that slices are a little dicey, and giving 
> the compiler a way to detect bogus usage of a slice will be good. 
> They're supposed to be a safer alternative to naked pointers, but 
> instead they introduce their own equivalently dangerous set of gotchas 
> due to the ambiguity of ownership.
> 
> Other than that, I think pretty much all of the changes Walter has 
> mentioned will be ignorable.
> 
> --bb