Do we need a time-out in D evolution?
gareis
dhasenan at gmail.com
Sun Jun 10 06:07:21 PDT 2007
Sean Kelly wrote:
> Walter Bright wrote:
>> eao197 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.
>>
>> 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++.
>
> I'll admit that one of my reservations about 'const' is the need to
> potentially write twice as many class methods. I don't suppose there's
> any way around this?
>
>
> Sean
Either you need to modify your function's parameter, in which case you
can't write a const version, or you don't need to modify your function's
parameter, in which case you just pass it in as const.
So how do you need to write additional methods?
-gareis
More information about the Digitalmars-d
mailing list