const methods


My number one biggest desire in C#, or complaint (if you choose)…  Are we ever going to see const methods, objects and properties?   I’m one of those who basically think languages we should actually be delimiting non-const items, and having everything default to const, but even though there are work-arounds, not having a const specifier I think encourages people (like me) to be lazy and write really dangerous code!


 


Const is very hard to do a multi-language environment. You would need to do it as part of metadata, and you would either only do it in some languages (which would reduce its universality), or require every language to support it (not a good thing).


 


My personal experience convinces me that const is a good idea in the small, but doesn’t work too well in the large. Whenever I tried it in C++, I’d always run into the case where a method that was const needed to not be const (and it wasn’t a case where mutable would have helped). At that point, I either needed to de-constify all call paths down to that function, or split the api into const and non-const versions. The first is a lot of extra work, and the second will decrease my overall quality.

Comments (15)

  1. J. Daniel Smith says:

    Yes, adding "const" after the fact is very difficult. And sometimes the semantics of "const" can be confusing (i.e., caching an expensive "get" value).

    Nevertheless, much of the time it really helps keep you honest. I’d also like to see the default be "const", adding "mutable" when needed.

  2. Jason G says:

    No, I don’t think const should be the default.

    If you need to have readonly classes, then there are ways to do that already.

    Also, I think there are people that would mistakenly believe that const would give them some security guarantees, in the same way that there are people that believe making a member private will protect them.

    The only thing const is really useful for IMHO, is for hinting that your method probably won’t modify that object. Of course, you can still hack around that and alter the object anyway.

    For instance, even if you did some fancy permission tricks to prevent me from accessing your raw memory, if I’m running with Full Trust (which is the default for client side right now) I can turn off CAS and negate your checks and 0wn your memory space.

    Const would only be synctatic sugar with no real teeth.

  3. Eric Newton says:

    so what if you can p0wn memory. anybody with half a brain and a debugger can do that.

    const was intended to discourage modifying the state of the object passed in, and the compiler had a duty to attempt to help.

    i hate the fact that i can pass in an object and the method can update a property without me really knowing about it.

  4. Jason G says:

    Okay, but it’s still going to lead to buggy code. There are current mechanisms in place that you can use to find out if your object has been modified.

    Events, comparing properties before and after, documentation, sending in a clone, etc.

    The problem is that const would be purely synctatic eye candy, and pretty much meaningless.

    If it is meaningless, but a lot of people would have a very strong tendency to assume it isn’t, then that makes it dangerous.

    If people treat it as a dangerous hint, and still have to do their checks to maintain safety, then what was the point of having it?

    Might as well just put it in an intellisense comment at that point.

    And let’s not even start on how it’s going to interoperate with other framework languages, let alone ILASM.

    If you want const, it’s going to have to go into the CLR, and every language is going to have to implement it. (With DRM type things coming up, who knows, it (or something similar) might actually make it in one day.))

  5. Mark T says:

    I have to agree that the lack of const is one of my only two complaints about C#. The second is generics and luckily that is coming around. I bothered to learn C# and then got discouraged by these two missing features that I use a lot in C++.

    I have been part of C++ efforts to "fix" const correctness in a few projects and it always turns up hidden bugs that would have been prevented had const correctness been used from the beginning.

    Normally pass by value will prevent the passed in variable (object) from being modified by accident since the called function only changes a copy of the variable (object), but when you want to be efficient and pass by reference (since you have large objects), you _need_ a way to distinguish the intent of passing in the reference: to modify or simply to read. You need a way to have a guarantee to the caller that the reference to the variable (object) is not used in an unintended way (i.e. to change its state). Documentation can certainly say this, but that has proven not to work. Having it right there in the language is a very positive enforcer.

    Just because some people do not understand how const can be used or are not able to use it properly does not mean that many of us do not or cannot use it properly.

  6. Kael Rowan says:

    I also agree that const would be an excellent addition to the language – even if it is only for C# and it only does compile-time checking. You wouldn’t be able to make things const by default since not all languages would support it, but it would help code purists maintain a sense of code integrity if they get a nice compiler error when they slip up and write Func(const MyClass o) { o.SomeProperty = “error here”; }. It may not have any runtime value but that doesn’t mean it wouldn’t be helpful for compile time completeness.

    Also I think anyone’s crazy who thinks code security (const fields or whatever) can prevent an application with Full Trust from doing whatever they want with your memory space 🙂 .NET may be powerful but not THAT powerful! (Well, maybe once we’ve got a 100% managed kernel 🙂 )

  7. re: Generic???? Part1: class constrain and struct constrain

  8. asdf says:

    "My personal experience convinces me that const is a good idea in the small, but doesn’t work too well in the large. Whenever I tried it in C++, I’d always run into the case where a method that was const needed to not be const (and it wasn’t a case where mutable would have helped)."

    My personal experience is the opposite and I’ve been programming C++ for a long time. Could you post some examples to back this up?

  9. Nick Hounsome says:

    My personal experience of C++ is that anybody who insists that const is a problem has a terrible design.

    Having said that – anybody who has ever attempted to fix up a large piece of code that doesn’t use const will know that (a) the person writing it should get another career and (b) there is no way it can be retrofitted to C#

    I also appreciate the previous comment about the difficulty of integrating const aware and non const aware languages.

    One suggestion is to follow the java route of providing readonly wrappers for at least all the main collections and interfaces. If you put all your modifiers for a class in an interface and work in terms of the interface then readomly wrappers can always be added later.

  10. Andrei Faber says:

    "My personal experience convinces me that const is a good idea in the small, but doesn’t work too well in the large. Whenever I tried it in C++, I’d always run into the case where a method that was const needed to not be const (and it wasn’t a case where mutable would have helped)."

    Yes, sounds terribly. Could you give an example?

  11. Oh yeah... says:

    Oh, leave Eric alone… If the "always be const-correct" preacher (Hurb Sutter) gives up on const, Eric is fully entitled to preach versus const too 😛

  12. Andrei Faber says:

    >> If the "always be const-correct" preacher (Hurb Sutter) gives up on const

    Hm… Could you give a bit more information? 🙂

  13. Andrei Faber says:

    >> If the "always be const-correct" preacher (Hurb Sutter) gives up on const

    Hm… Could you give a bit more information? 🙂

  14. MBA says:

    Helpful For MBA Fans.