I know there are different posts related to questions around this topic, but I couldn't find any source on the question I have.

In some scenarios, it would be much easier, if value types behaved as reference types, i.e. they could be modified inside another method. For example I want to track some value types of type int and pass several of them to a method, and that method may modify them. And let's assume, that after execution of the method I will need to use the updated values on the caller side. Of course there are multiple ways to achieve this, but the thing is that it would be just much simpler to pass those integers to a method, that could return void, yet we still get the updated values of those integers, as we hold the references.

As far as I know, there are no such wrappers/classes in C# that represent the same experience like the value types do, yet being reference type. (For example for int, the wrapper still should do , --, have the same range, etc.)

So my question is why there is no such alternative in the language? My assumptions are because of the ambiguousness and to have a single straight way to do things. And to get rid of some small headaches of comparing two equal values that are of different types, etc. And in case someone really needs that, he/she can implement that.

What are your thoughts on this topic? And why the language should NOT have that kind of wrappers of the value types?

CodePudding user response：

For example I want to track some value types of type int and pass several of them to a method, and that method may modify them.

Note the emphasis on "several". This is a perfect opportunity to create an object. So instead of this:

UpdateValues(value, anotherVal, 12, someString, etc);

You would have this:

UpdateValues(valuesToUpdate);

Any property on that object that you set within that method will indeed be reflected on the object itself. Because there's only one instance of that object. You're not setting a value to a variable, you're updating a property on a reference.

Basically, instead of passing around bare values, compose meaningful objects and use those. Those objects can be filled with all the business logic you like, can be modified in any way that you like, etc.

As for debates and opinions about why a language does or does not have any given feature that you personally may want it to have...

We could spend all day coming up with contrived examples, debating the need for it, whether it would make code simpler or more complex, other pros and cons, etc. But someone who has worked on a major language has already said it better. To paraphrase for this question:

That's the wrong question to ask. Instead, ask: "Is there a compelling reason to implement and support this feature?" If there isn't, none of the rules for supporting this feature needed to be thought of, argued about, designed, specified, implemented, tested, documented, shipped to customers, or made compatible with every future feature of C#. That is a significant cost savings.