Question

Say instead of returning void a method you returned a reference to the class even if it didn’t make any particular semantic sense. It seems to me like it would give you more options on how the methods are called, allowing you to use it in a fluent-interface-like style and I can’t really think of any disadvantages since you don’t have to do anything with the return value (even store it).

So suppose you’re in a situation where you want to update an object and then return its current value. instead of saying

myObj.Update(); var val = myObj.GetCurrentValue(); 

you will be able to combine the two lines to say

var val = myObj.Update().GetCurrentValue(); 

---

EDIT: I asked the below on a whim, in retrospect, I agree that its likely to be unnecessary and complicating, however my question regarding returning this rather than void stands.

On a related note, what do you guys think of having the language include a new bit of syntactic sugar:

var val = myObj.Update()<.GetCurrentValue(); 

This operator would have a low order of precedence so myObj.Update() would execute first and then call GetCurrentValue() on myObj instead of the void return of Update.

Essentially I’m imagining an operator that will say ‘call the method on the right-hand side of the operator on the first valid object on the left’. Any thoughts?

Answer 1

I know in Java they’re actually thinking about making this standard behaviour for void methods. If you do that you don’t need the extra syntactic sugar.

The only downside I can think of is performance. But that’s easilly measured. I’ll get back to you with the results in a few minutes 🙂

Edit:

Returning a reference is a bit slower than returning void .. what a surprise. So that’s the only downside. A few more ticks when calling your function.