Hacker News Reader

Comment by codeulike | Hacker News Reader

The complaint about 'implicit information loss' is a bit weird, the code calls a function/method that may do other things, the compiler doesn't know whether you intend to ignore what's returned or not. To return 'true' when you meant to return the result of the function call on the previous line is just a bug. There are going to be bugs.

View on HN

C++ introduced the [[nodiscard]] attribute for this exact use case. A C# [NoDiscard] attribute would do the same thing with the help of a Roslyn analyzer I guess.

C# already by default warns on discarded return values.

No it does not, unless the discarded value is a Task in an async method. (or sometimes an IDisposable depending on what analyzers you have running)

I think what he meant is the different (implicitly assumed by human brain) output of those two statements:

someList.Add(obj); someStr.Format(„%d“);

While the first one cleary modifies the list someList, the second one only _returns_ the modified string and someStr’s value does not change. IMHO fornatted text is a different (new) object therefore I don‘t see his issue, and I also think there‘s a shift towards immutable, which would clear such a thing up.

I feel like your example is talking about having the result "in-place" or not, which is an entirely different from what he's complaining (semicolon suspends output).

> In project programming this hit me this week with a bug: > value.Format(...); > return true; > when I actually wanted > return value.Format(...); > This is "implicit information loss" [..]

I don‘t see any semicolon missing.

Oh sorry, didn't notice you're talking about the first half of point #1.

To be honest, I have no idea what he's expecting with that "return true". How would that be different in any other language?

I think he‘s expecting someStr.Format() to format the value of the object someStr _instead_ of returning a new object containing the fornatted string.

Reply on news.ycombinator.com