Timeline for Read-only ("const"-like) function parameters of C#
Current License: CC BY-SA 3.0
Post Revisions
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 13, 2022 at 6:19 | comment | added | RBT | Related post - Const function parameter in C# | |
| Sep 15, 2020 at 23:08 | comment | added | XWiśniowiecki |
You can use in keyword.
|
|
| Sep 15, 2020 at 23:01 | answer | added | XWiśniowiecki | timeline score: 9 | |
| May 6, 2012 at 21:53 | history | edited | Pops | CC BY-SA 3.0 |
sp/gr
|
| Sep 30, 2010 at 13:14 | comment | added | Eric Lippert | @Timwi: Of course I've entertained that possibility. I'm attempting to confirm or eliminate it by asking focussed questions to determine the true scope of the problem. (As for "proternal", I think you are mischaracterizing my position. It would be nice to have, and if we'd had it since v1, that would be fine with me. But "nice to have" doesn't make the bar for the expense of adding it now. Regardless, this is a distraction from the original poster's question which I am attempting to clarify.) | |
| Sep 30, 2010 at 13:01 | comment | added | Timwi | @Eric: Are you sure that you have fully entertained the possibility that the requested functionality may have nothing to do with security or hostile code? It may well be the case that all the OP is after is the kind of compile-time checking that const provides in C++, which he is familiar with and whose security limitations he is probably aware of. The same is true of people who request “protected and internal” and similar compile-time checking features on your blog: you seem to reject these ideas simply because they do not improve security against hostile code, but that misses the point. | |
| Sep 30, 2010 at 12:15 | comment | added | Eric Lippert | @Timwi: I'm attempting to determine the situation actually faced by the original poster. The OP states that the client should have read-only access to the data but not the consequences for failure of that policy. If the consequences of a hostile, fully-trusted client subverting the system to write the data are bad for the business model of the service provider then trivially wrapping a read-only wrapper around the data is insufficient. I'm not making any statement about the design of the access modifiers and their interaction with reflection and code access security in the CLR. | |
| Sep 30, 2010 at 11:24 | comment | added | Timwi | @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”? | |
| Sep 30, 2010 at 9:11 | comment | added | Roman Starkov | @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#. | |
| Sep 30, 2010 at 4:47 | comment | added | Eric Lippert | Merely making the interface provide read capability might not be sufficient. First: is the client presumed to be actively hostile to you? Is the person writing the "client" side of the application actively attempting to subvert the "service provider" side that you have implemented? Second: is the hostile client fully trusted by the user running the client code? The security system is designed to protect *users, not software providers. If you as a software provider need protection from hostile, full-trust users who want to subvert your code, then you have a hard problem to solve. | |
| S Sep 29, 2010 at 23:57 | vote | accept | MarkP | ||
| Sep 29, 2010 at 23:56 | vote | accept | MarkP | ||
| S Sep 29, 2010 at 23:57 | |||||
| Sep 29, 2010 at 23:56 | vote | accept | MarkP | ||
| Sep 29, 2010 at 23:56 | |||||
| Sep 29, 2010 at 23:52 | comment | added | MarkP | @Eric: Technically the person that implements SomeFunction() will not be me, rather, the 'client'. Therefore, I would like for him/her to have access to my data, but not be able to modify it. | |
| Sep 29, 2010 at 23:46 | comment | added | Timwi | @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. | |
| Sep 29, 2010 at 23:46 | answer | added | Phil Gilmore | timeline score: 2 | |
| Sep 29, 2010 at 23:35 | answer | added | Timwi | timeline score: 15 | |
| Sep 29, 2010 at 23:35 | comment | added | MarkP | No it does not, but it does offer some protection within the scope of the function (unless you strip the const away via casting). | |
| Sep 29, 2010 at 23:34 | comment | added | Eric Lippert | 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? | |
| Sep 29, 2010 at 23:28 | comment | added | Eric Lippert | 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#. | |
| Sep 29, 2010 at 23:21 | answer | added | Brian Rasmussen | timeline score: 4 | |
| Sep 29, 2010 at 23:08 | history | asked | MarkP | CC BY-SA 2.5 |