C# Reference Type alternatives to Value Types

Question

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?

Do you mean passing by ref? `public void SomeFunction(ref int valueToModify)` — hijinxbassist, Sep 14 '21 at 17:33
Yes, you can do that, but you cannot use those modifiers with async methods — David Oganov, Sep 14 '21 at 17:35
Does this answer your question? [ref and out arguments in async method](https://stackoverflow.com/questions/20868103/ref-and-out-arguments-in-async-method) — Mauricio Gracia Gutierrez, Sep 14 '21 at 17:44
Are you searching for a [mutable](https://stackoverflow.com/questions/7787994/is-there-a-version-of-the-class-tuple-whose-items-properties-are-not-readonly-an) equivalent of [`Tuple`](https://learn.microsoft.com/en-us/dotnet/api/system.tuple-1)? — Theodor Zoulias, Sep 14 '21 at 17:46
Guys, thanks for your comments. As I've said there are multiple ways to achieve same result. But the question is more abstract. Why guys at Microsoft haven't taken another path? — David Oganov, Sep 14 '21 at 17:50
Maybe you could ask them directly, using the microsoft forums — Mauricio Gracia Gutierrez, Sep 15 '21 at 12:36

score 3 · Accepted Answer · answered Sep 14 '21 at 17:42

3

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.

answered Sep 14 '21 at 17:42

David

208,112
36
198
279

First, thanks for your wonderful answer. I really appreciate it. Of course if you have multiple arguments passed to a method, then, probably, you are doing something wrong. But sometimes the arguments are not that related to each other, and, especially when solving algorithm, problems, it's easier to do things quickly, w/o defining models. And I just wish sometimes, that the language offered something more handy for the scenario. But the last part of your answer perfectly answers my question: it just not worth it. There are better things to focus on and to deliver. Thank you! – David Oganov Sep 14 '21 at 17:54
2

@DavidOganov: *"sometimes the arguments are not that related to each other"* - Being passed to the same operation is itself a relation. Even if you just build that object for the purpose of calling that method and then decompose it again afterward, that object has a semantic and conceptual purpose for existing. *"it's easier to do things quickly"* - "Quickly" does not always translate directly to "correctly" or "easier to support and maintain". Lots of programmers claim they want to do something "to keep it simple" and end up making things more complex for themselves in the long run. – David Sep 14 '21 at 17:58
I 100% agree. Long-term focus is much more important. And not looking ahead will most probably bring to big problems sooner or later. But it's still interesting to me whether engineers at Microsoft considered similar approach as my question. As they ended up developing more features to overcome the problems. Of course there are downsides as well. But seems I'm starting to move towards debates/opinions :D – David Oganov Sep 14 '21 at 18:06
1

@DavidOganov: Honestly, and this may be a big ask, you would likely find the best answer to your question by... designing a language. There are a variety of simple languages used for academic or esoteric purposes and it could be pretty interesting to grab one and modify it for your ideas. You might find it to not be worth your time, in which case the answer is that there are reasons you don't know about and that's it. Or you may find that the feature causes more problems than it solves. *Or* you may find that it works really well if only for a specific subset of functionality. – David Sep 14 '21 at 18:09
I see... Thank you, David. I really enjoyed your answer and communication. I really feel the experience and knowledge you have in every sentence of yours. Thank you for your time and sharing your knowledge & experience. I really appreciate it – David Oganov Sep 14 '21 at 18:12

C# Reference Type alternatives to Value Types

1 Answers1