5 ms·

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

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.

frabert 6y ago
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.
- goto11 6y ago
  C# already by default warns on discarded return values.
  - algorithmsRcool 6y ago
    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)
chrisandchris 6y ago
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.
- fireattack 6y ago
  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).
  - chrisandchris 6y ago
    > 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.
    - fireattack 6y ago
      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?
      - chrisandchris 6y ago
        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.

frabert 6y ago

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.

goto11 6y ago
C# already by default warns on discarded return values.
- algorithmsRcool 6y ago
  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)

chrisandchris 6y ago

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.

fireattack 6y ago
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).
- chrisandchris 6y ago
  > 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.
  - fireattack 6y ago
    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?
    - chrisandchris 6y ago
      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.