Do we need a time-out in D evolution?

[eao197]

On Sun, 10 Jun 2007 08:00:30 +0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

>> I don't agree with you. As a C++ programmer I'm big fun of 'const' --  
>> it have saved me from bugs several times. So when const became a part  
>> of D I certaintly rewrite my code with use of const/final/invariant. To  
>> show you how it can affect my project I can say -- in one my rather big  
>> C++ library (~46K lines) there are 121 *.hpp files with ~280 const  
>> methods and ~900 const parameters. I think it is not too easy to write  
>> all that staff without const at first and then carefully rewrite and  
>> retest it with const.
>
> My experience with const-correctness is you can largely ignore it unless  
> you are writing libraries. If you are transforming bug-free, tested code  
> into const-correct code, it won't need much testing. Adding const isn't  
> likely to break anything at runtime, just at compile time.

But I'm mostly library writer than application writer. On my work I write  
domain-specific or more general purpose libraries which then used in  
application development by me and my colleagues.

A long time ago I had some expirience of modifying C++ code without consts  
to code with consts. Main trouble was to identify methods which must be  
declared as const -- it required full code review.

> Also, although the design is a bit on the complex side, I don't think  
> that complexity will show through much in user code. With type inference  
> and 'in' parameters, I don't think you'll have to write 'const' all that  
> often - certainly much less than in C++.

May be you right. But as I can see main problem with porting D code to D  
code with const will be const methods in classes, not const parameter nor  
const inside methods.

-- 
Regards,
Yauheni Akhotnikau