25

Coming from a C++ background, I'm used to sticking the const keyword into function definitions to make objects being passed in read-only values. However, I've found out that this is not possible in C# (please correct me if I'm wrong). After some Googling, I arrived at the conclusion that the only way to make a read-only object is to write an interface that only has 'get' properties and pass that in instead. Elegant, I must say.

public interface IFoo { IMyValInterface MyVal{ get; } } public class Foo : IFoo { private ConcreteMyVal _myVal; public IMyValInterface MyVal { get { return _myVal; } } }

I would pass it into:

public void SomeFunction(IFoo fooVar) { // Cannot modify fooVar, Excellent!! }

This is fine. However, in the rest of my code, I would like to modify my object normally. Adding a 'set' property to the interface would break my read-only restriction. I can add a 'set' property to Foo (and not IFoo), but the signature expects an interface rather than a concrete object. I would have to do some casting.

// Add this to class Foo. Might assign null if cast fails?? set { _myVal = value as ConcreteMyVal; } // Somewhere else in the code... IFoo myFoo = new Foo; (myFoo as Foo).MyFoo = new ConcreteMyVal();

Is there a more elegant way of replicating const or making read-only function parameters without adding another property or a function?

Improve this question
13
  • 3
    Just to comment on your first sentence: that is not what "const" does. The referent is still mutable. Consider for example a method that takes two references to a type C, one marked const, one not. Pass a reference to the same variable for both references. If you mutate the non-const reference then the const reference will observe the mutation. const does not provide a guarantee of read-onlyness that you can rely upon. Nor does it prevent mutation of a mutable object, since it can be cast away. That is very different from readonly fields in C#. Commented Sep 29, 2010 at 23:28
  • 3
    To address your actual question: this is a confusing question. You seem to be saying that you want both (1) a guarantee of read-only-ness and (2) the ability to mutate the object. Those are opposites. You can't have both of them. Can you explain why you want SomeFunction to not be able to induce a mutation? Is this for security purposes? Is it for correctness? Who is providing the implementation of SomeFunction? If it's you, then why do you need it to be const? If you don't want to write a mutation, then don't. If it is someone else, then why do you care if they induce a mutation? Commented Sep 29, 2010 at 23:34
  • 6
    @Eric: It makes sense to limit the capabilities of SomeFunction even if I am the one writing it. It increases compile-time checking to validate against accidental mistakes. (I’m sure you’ve made mistakes before — can you not imagine yourself making this kind of mistake where you accidentally mutate a variable when you weren’t supposed to?) I think the question asker doesn’t want a guarantee of read-only-ness, he only wants a semi-guarantee that this method won’t mutate this object when accessing it through the parameter. Commented Sep 29, 2010 at 23:46
  • 3
    @Eric I think the idea here is compile-time bug finding, rather than security. I know that C# implements all the "traditional" ways to do this, but doesn't seem to be very receptive of the more recent approaches - like the ones being researched in Spec#. Commented Sep 30, 2010 at 9:11
  • 2
    @Eric: “Merely making the interface provide read capability might not be sufficient.” — For security, of course not! But for some reassurance that I’ve not made a certain class of mistakes, it is a pretty good start. Why does the “private” access modifier exist? It is clearly not sufficient for security because Reflection can subvert it. Does that mean it shouldn’t exist and we should all use “internal” instead? How are the security characteristics of “private” any different from “internal”? Commented Sep 30, 2010 at 11:24

4 Answers 4

Reset to default
15

I think you may be looking for a solution involving two interfaces in which one inherits from the other:

public interface IReadableFoo { IMyValInterface MyVal { get; } } public interface IWritableFoo : IReadableFoo { IMyValInterface MyVal { set; } } public class Foo : IWritableFoo { private ConcreteMyVal _myVal; public IMyValInterface MyVal { get { return _myVal; } set { _myVal = value as ConcreteMyVal; } } }

Then you can declare methods whose parameter type “tells” whether it plans on changing the variable or not:

public void SomeFunction(IReadableFoo fooVar) { // Cannot modify fooVar, excellent! } public void SomeOtherFunction(IWritableFoo fooVar) { // Can modify fooVar, take care! }

This mimics compile-time checks similar to constness in C++. As Eric Lippert correctly pointed out, this is not the same as immutability. But as a C++ programmer I think you know that.

By the way, you can achieve slightly better compile-time checking if you declare the type of the property in the class as ConcreteMyVal and implement the interface properties separately:

public class Foo : IWritableFoo { private ConcreteMyVal _myVal; public ConcreteMyVal MyVal { get { return _myVal; } set { _myVal = value; } } public IMyValInterface IReadableFoo.MyVal { get { return MyVal; } } public IMyValInterface IWritableFoo.MyVal { // (or use “(ConcreteMyVal)value” if you want it to throw set { MyVal = value as ConcreteMyVal; } } }

This way, the setter can only throw when accessed through the interface, but not when accessed through the class.

Improve this answer
Sign up to request clarification or add additional context in comments.

14 Comments

What stops the client from casting the IReadable to an IWriteable and writing away to their heart's content?
@Eric: What stops Console.WriteLine from formatting my hard disk? Nothing except for the fact that it tries to fulfill its contract.
My point is that this is not actually using the type system as enforcement but rather as polite suggestion. If that's the goal then fine, you're done. But I and others are frequently in situations where polite suggestion is not enough; if the value actually needs to provide no mechanism whereby a mutation can occur via verifiable use of the type system then this is insufficient. It's the same reason why you can't just cast an array to IEnumerable<T> and return it; someone could still mutate the array. If that is the situation the OP is in then an immutable wrapper object is better.
@MoneyOrientedProgrammer: A good design principle in C# is that a method that produces a value should be free of side effects because otherwise it becomes impossible to compute the value if you don't want the effect. Your belief that const prevents methods from having side effects is false, but lots of people believe it, and that's why const is a dangerously badly designed feature in my opinion.
@MoneyOrientedProgrammer: The problem that we run into is that there is a big difference between observable effects and implementation detail effects. Consider an expensive recursive algorithm marked as const, for example. We cannot as a performance improvement memoize the method within the class without removing the const, because memoization is by definition a side effect: it changes what is remembered. We end up having to jump through crazy hoops to maintain const correctness.
|
9

The closest equivalent is the in keyword. Using in makes the parameter and input parameter and prevents it from being changed inside the method. From the official C# documentation:

  • in - specifies that this parameter is passed by reference but is only read by the called method.
  • ref - specifies that this parameter is passed by reference and may be read or written by the called method.
  • out - specifies that this parameter is passed by reference and must be written by the called method.

enter image description here

Improve this answer

2 Comments

in won't prevent you from modifying reference types (classes), as in the question. And for mutable structs it will do defensive cloning if you call any methods of the input struct.
Also looks like you can't use in with lambas or async methods, which makes it unusable in many cases
4

First of all, you're correct: you cannot apply const or a similar keyword to parameters in C#.

However, you can use interfaces to do something along those lines. Interfaces are special in the sense, that it makes perfect sense to make an interface that only covers a specific part of a feature set. E.g. image a stack class, which implements both IPopable and IPushable. If you access the instance via the IPopable interface, you can only remove entries from the stack. If you access the instance via the IPushable interface, you can only add entries to the stack. You can use interfaces this way to get something similar to what you're asking for.

Improve this answer

Comments

2

Consider Timwi's answer first. But as a second option, you could do this, making it more like the C CONST keyword.

Reference-type (object) parameters are IN parameters by default. But because they are references, their method side effects and property accesses are done to the object outside the method. The object doesn't have to be passed out. It has still been modified by the method.

However, a value-type (struct) parameter is also IN by default, and cannot have side effects or property modifications on the element that was passed in. Instead, it gets COPIED ON WRITE before going into the method. Any changes to it inside that method die when the method goes out of scope (the end of the method).

Do NOT change your classes to structs just to accommodate this need. It's a bad idea. But if they should be structs anyway, now you'll know.

BTW, half the programming community doesn't properly understand this concept but thinks they do (indeed, I've found inaccuracies on the matter of parameter direction in C# in several books). If you want to comment on the accuracy of my statements, please double check to make sure you know what you're talking about.

Improve this answer

6 Comments

It should be pointed out that using structs only has the effect of discarding changes to the object, which the compiler will happily allow. This means the author of the method can make changes to the object and then potentially get confused because they don’t persist. The intention of const in C++, and the interface-based solution in C#, is to send a signal that the method is not supposed to make changes and that the compiler should consider the attempt an error.
Not sure why you go to such pains to highlight that all parameters are "in" by default, since you can't pass a value to modify using an "out" parameter anyway... Your distinction is between classes & structs and how they behave under pass-by-value - in/out has nothing to do with it as far as I can see. Is there a reason for your emphasis?
@Dan: I can’t speak for Phil, but I think it does make sense to point out that the statement “Any changes to it inside that method die” only applies if the parameter is not marked ref.
@Timwi: Agreed, but that's nothing to do with "in" or "out". You can't pass a value in through an out parameter! By value versus by reference isn't the same as an out parameter.
@Dan: Well that’s not what the answerer meant. I believe he meant “in” (the default) as opposed to out or ref (which have to specified explicitly). You can’t pass a value in through an out parameter, but through a ref parameter you certainly can.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.