23

Unlike C++, there aren't any const member method and const parameters in C#. What is the reason?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
user496949
  • 83,087
  • 147
  • 309
  • 426
  • See these duplicate questions: http://stackoverflow.com/questions/3263001/why-const-parameters-are-not-allowed-in-c http://stackoverflow.com/questions/114149/const-correctness-in-c – Yoshi Nov 11 '10 at 00:47
  • Related post - [Const function parameter in C#](https://stackoverflow.com/q/10981888/465053) – RBT Jan 13 '22 at 06:19

2 Answers2

28

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.

Eric Lippert
  • 647,829
  • 179
  • 1,238
  • 2,067
  • 24
    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 Nov 11 '10 at 00:49
  • 18
    (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*. – Ben Voigt Nov 11 '10 at 00:52
  • @Ben Voigt: If I do something that is forbidden, I want the application to refuse to compile. If detecting the forbidden behavior at runtime is not possible, I want it to have a defined failure method at runtime (e.g., throwing an exception). – Brian Nov 11 '10 at 14:18
  • 9
    @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. – Eric Lippert Nov 11 '10 at 15:58
  • @Eric: since you said "... it is far weaker than any other guarantee that we would like to make in the type system", does it mean you guys are looking for true immutability guarantee in the type system (not sure what this would be called)? If so, do you think it's in the plans for C# and .NET 5? Would seem like that would be a great version to have these, just in my opinion of course :O – Joan Venge Nov 11 '10 at 18:49
  • 1
    @Joan: I personally would love to have an immutability guarantee made by the type system that is stronger than 'readonly' on a field. I would particularly love a write-once 'readonly' array type that is fast, small and safe. That sort of stuff is not in the plans for any time soon, but is always on the list of stuff to investigate for possible future hypothetical features of possible future hypothetical products. – Eric Lippert Nov 12 '10 at 01:09
  • @Eric: Thanks for your insight. Out of curiosity, why do you just want a write-once 'readonly' array, not other types in addition to arrays? Reason I ask is, I wonder the use of that kind of thing. Surely it must be useful but don't know it myself. I will spread the word if I know about it so who knows then your feature will be requested enough to be put in sooner than later :O – Joan Venge Nov 12 '10 at 18:38
  • 2
    @Joan: The biggest problem with arrays is that they are arbitrarily mutable and therefore are not safe to cache. But all their other properties are *really nice*. They take up almost *exactly* the necessary amount of space, with very small overhead. They are extremely fast to index. They can be passed around cheaply by reference. And so on. – Eric Lippert Nov 12 '10 at 19:24
  • 1
    @Joan: Immutable arrays could also be *safely* covariant, which would be nice. The thing about arrays is that arrays have a lot of special-purpose handling in the CLR itself. It would be nice to have special-purpose treatment for immutable arrays too, which makes the feature a lot harder. (All that said, I'd love to have other immutable collection types too!) – Eric Lippert Nov 12 '10 at 19:39
  • @Eric: Thanks Eric, really helpful to hear your ideas about it. Why isn't Microsoft listen to guys like you and dedicate one release for all the features and changes you guys would think be useful? I imagine this would bring the language and the platform to much more superior levels, right? After all you know much more than most programmers in terms of what would be most beneficial, etc. – Joan Venge Nov 12 '10 at 19:54
  • 1
    @Joan: They *do* listen to people like me who have ideas for what would be useful. They listen to *tens of thousands of people like me*, and all of those people have different ideas about what is the most awesome thing that should be added to the CLR. Only the very best few of all those possible features get implemented. – Eric Lippert Nov 12 '10 at 20:01
  • @Eric: Thanks Eric, I see what you mean now :O – Joan Venge Nov 12 '10 at 20:10
  • 17
    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. – Jan Hudec Mar 06 '14 at 10:45
  • 12
    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. – Syndog May 23 '14 at 19:20
  • 3
    Const correctness is a mayor success in C++. It's not about guarantee, it's about contracts and the compiler helping you write correct code. – chila Nov 15 '15 at 04:24
  • @chila: Let's suppose for the moment that your assertion is true, for the sake of argument. Is any part of your statement a justification for doing the same feature in C#? No. The actual thrust of the argument is: design by contract and a compiler that helps you write correct code are goodness; immutability constraints are an important and successful attack on the problem of managing complex state; therefore the C# design team should consider features *in keeping with the spirit of C# and the existing CLI mechanisms* that further these ends. – Eric Lippert Nov 15 '15 at 09:31
  • 1
    @EricLippert Both statements in my comment are true. I challenged your statements and the output was success. In no part of my comment I spoke about justifications. – chila Nov 15 '15 at 14:30
  • @chila: OK, but *that's what the original question is about*: does the success of the feature in C++ justify the feature in C#? Saying that the feature is a success in one language, and saying that it is one way for the language to encourage quality, sure, those things are true, but I don't see what they have to do with this question. – Eric Lippert Nov 15 '15 at 15:19
  • 1
    @EricLippert They where corrections to your false statements. – chila Nov 15 '15 at 20:24
  • 1
    @chila: Well, then I encourage you to write an answer that you think is a better answer to the stated question; that way we all get to benefit from your knowledge. – Eric Lippert Nov 15 '15 at 21:42
  • @EricLippert And I encourage you be open to corrections to what you say. – chila Nov 15 '15 at 21:55
  • Looking at this conversation many years later and it is almost funny -- Rust for example almost has constness as a core language feature, which says that there is a way to have an implementation that is not broken. Of course I'm not saying it's easy to bring the same model to C# or CLR, but this gives some inspirations – Zhe May 06 '23 at 11:32
9

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.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Ben Voigt
  • 277,958
  • 43
  • 419
  • 720