preparing for const, final, and invariant

[Bill Baxter]

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.

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