Sam, const makes little sense if it is not used by everyone. For instance, if the Base Class Library does not declare its parameters and methods as const, what would you do with your own const arguments if you had to pass them to BCL methods? Right, cast away const, all the time. With all those VB developers out there, MS probably felt that there is little chance of a good and consistent use of const throughout the .NET world.
On the other hand, there is a lot to say for const in the CLR. Other than C++, the CLR could guarantee that const arguments are not modified (using IL verification). Code access security could allow trusted assemblies to still cast it away. The main problem is that currently, if I want to be sure that my parameters are not modified, I have to pass a copy (which can be very expensive). In this thread, someone mentioned that only ref and out parameters are changed anyway. Yes, agreed, but the objects that are referenced by your parameters can still be changed, so that's no solution. So the bottom line is that yes, const would definitely be a very good idea for the next version of C#, provided that the BCL (which is mostly written in C# anyway) makes use of this construct. But the concept of const should be defined at the CLR level, so that other languages can coose to conform. It doesn't have to be in the CLS however, I really don't see your average VB programmer making good use of const. So let's all sign a petition, yes? BTW, Managed C++ uses custom attributes to declare its arguments as const in metadata, but if I reference a MC++ assembly from MC++, it ignores the consts. Funny. Stefan You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
