Unlike C++, there aren't any const member method and const parameters in C#. What is the reason?
- See these duplicate questions: stackoverflow.com/questions/3263001/… stackoverflow.com/questions/114149/const-correctness-in-cYoshi– Yoshi2010-11-11 00:47:24 +00:00Commented Nov 11, 2010 at 0:47
- Related post - Const function parameter in C#RBT– RBT2022-01-13 06:19:41 +00:00Commented Jan 13, 2022 at 6:19
Add a comment |
2 Answers
First off, there is no requirement that we provide a reason for not implementing a feature. Features are extremely expensive; there has to be a justification for implementing a feature, not a justification for not implementing a feature.
Second, C# is not a clone of C++ or C. Just because a feature is in some other language is not a reason to put it in C#.
Third, "const" is deeply, tragically broken in C and C++. "const" gives you no guarantee that you can actually rely upon. If you are the caller of a method that takes a const reference then you have no guarantee whatsoever that the method honours the constness; the method has many ways of mutating a const reference. If you are the consumer of a const reference then you have no guarantee that the underlying object actually will not mutate arbitrarily. Since the contract is not enforced on either the caller or the callee side, it is far weaker than any other guarantee that we would like to make in the type system. We would not want to replicate such a broken system.
Fourth, putting constness in the CLR type system means that every language would have to use the same implementation of constness; since different languages have different meanings for constness, that would be making it harder to bring more languages to the CLR, not easier.
There are many reasons for not doing this extremely expensive feature, and very few reasons to do it. Expensive, unjustified features don't get implemented.
21 Comments
Ben Voigt
You're right that the consumer of a
const reference can't expect that the referent will not be modified elsewhere. const (as a qualifier on pointers and references) is all about sharing a read-only view of an object, not making objects immutable. But I disagree that it's useless. If a function accepts a const reference (or pointer-to-const), it had better not try to modify the referenced object, except as allowed by the mutable modifier, because I might have passed in a truly constant object stored in read-only memory.Ben Voigt
(continued) C++
const_cast (and equivalent mechanisms for stripping const) are forbidden unless the function can guarantee that the object was not const at the point of definition, which effectively limits their use to private internal helper functions. For a public API in C++ to try to modify an object passed in via const reference (or pointer) violates the standard and invokes undefined behavior.
Eric Lippert
@Ben: I did not say that const in C++ is useless. It is very useful. I use it all the time. I said that it was unreliable, misleading and dangerous. There are plenty of things that are unreliable, misleading and dangerous that are still of use. That's not the question at hand. The question at hand is "should the C# language replicate this unreliable, misleading and dangerous feature?" and the answer is "no" because the benefit of implementing a questionable design does not justify the large cost of doing so.
Jan Hudec
Const is not broken in C/C++ and it is not misleading either. It guarantees exactly as much as any other type information. C and C++ have weak typing. Type information never gives any guarantee there. It is nevertheless excellent tool for catching mistakes.
Syndog
You're talking "suck and blow" semantics when it comes to feature justification. If a feature is deemed useful, it's perfectly valid to question why it wasn't included. A more appropriate summation would be to say the feature's implementation cost outweighed its benefits, rather than dismissing the question as invalid as a matter of principle.
|
C# doesn't have it because .NET doesn't. .NET doesn't because the CLR development team decided it wasn't worth the effort.
You can read on MS blogs like Raymond Chen's "The Old New Thing" or Eric Lippert's "Fabulous Adventures in Coding", how Microsoft prioritizes features.
