Herfried,
The 'const' attribute could be stored as an attribute in the parameters'
metadata, similar to how it is done for optional parameters and parameter
default values. That's not the problem.
Ok. That was my understanding.
The main problem I see is that the .NET Framework's class library currently
does not make use of such an attribute, but this would be crucial for its
overall success because most of the code makes calls to this class library.
In addition, all 3rd-party code would have to be reworked to make use of
const-correctness.
In my experience with C++, I've made use of the Win32 API which is
written in C, which doesn't use "const" (please correct me if I am
wrong). But, I still implemented "const" myself, for my own
libraries, and derived a benefit from them.
But, I do see your point. If almost ALL of the program's data is
passed to library calls, and this data disallows change, the library
functions will complain that they are expected data they are allowed
to modify.
However, consider a next generation .NET could implement "const" --
even only partially -- to the library, without any detriment to
existing code. A function that never changed its parameter data will
not care that it is no longer allowed to change it. Also, such
functions will continue to accept ANY type of data (readonly or not).
VB programmers could continue on with no knowledge of the changes...
No major internal architectures must change to make this happen, as we
seen with the VB6 to VB.NET switch. And, it can be introduced
incrementally. This is Good News.
Zytan