3 ms·

"Implicitly discarding information" is just outright wrong. All calls can have side effects, even calls that return a value. And while C# did recently add the

"Implicitly discarding information" is just outright wrong. All calls can have side effects, even calls that return a value. And while C# did recently add the discard operator _ to throw away returned values out of an e.g. Tuple, if you did as this critique suggests and flag every "discarded information" the language would become verbose/obnoxious. For example: try { [....] myFirstDatabaseTransaction.Commit(); // Compiler warning: "Discarded Information" (it returns the transaction ID, but has the side effect of committing your changes to the database). } catch([...]) { [...] } Basic programmer errors are easily caught during development, because they're immediately wrong. Unlike null reference exceptions which sometimes can only be found after extensive usage of the system (due to different states, or underlying data changing).

yyyk 6y ago
"All calls can have side effects" - this isn't the case for a "pure" function. What the author wants would make some code worse but is very useful for anything working with immutable collections [IMHO, reading #4 that's what's behind his complaints - working in a functional/immutable style where C# isn't entirely comfortable]. There could be a middle ground where certain function calls do warn/error on such use and most others do not.
Smaug123 6y ago
F# solves this by making it a compile error to fail to consume an expression that returns anything other than unit. If you really must do this, you normally use `ignore : 'a -> unit`. It's unidiomatic F# to structure your APIs in such a way that you will routinely throw away the information you're given.
- Gibbon1 6y ago
  I think really what people want are strict and sleazy compile options. Or better the ability to tell the compiler that a return value is an error. Or not. If it's not an error and it gets tossed who cares really. Sometimes you don't care if every i is dotted and every t crossed.
rndgermandude 6y ago
And nullable helps with null references as well as intellisense warnings. Moreover that examples the author did are likely both oversimplified and wrong. In the first one, a bool then a string is returned which should raise a type error in most cases (unless you do an anonymous function and feed the result back into something that accepts an object-typed parameter/use an object-typed variable to store the result). I don't even know what's up with the second one; that's simply not valid code - if it was a normal function you cannot omit the trailing semicolon, and if it was a anonymous lambda you cannot have a trailing semicolon.

yyyk 6y ago

"All calls can have side effects" - this isn't the case for a "pure" function. What the author wants would make some code worse but is very useful for anything working with immutable collections [IMHO, reading #4 that's what's behind his complaints - working in a functional/immutable style where C# isn't entirely comfortable]. There could be a middle ground where certain function calls do warn/error on such use and most others do not.

Smaug123 6y ago

F# solves this by making it a compile error to fail to consume an expression that returns anything other than unit. If you really must do this, you normally use `ignore : 'a -> unit`. It's unidiomatic F# to structure your APIs in such a way that you will routinely throw away the information you're given.

Gibbon1 6y ago
I think really what people want are strict and sleazy compile options. Or better the ability to tell the compiler that a return value is an error. Or not. If it's not an error and it gets tossed who cares really. Sometimes you don't care if every i is dotted and every t crossed.

rndgermandude 6y ago

And nullable helps with null references as well as intellisense warnings. Moreover that examples the author did are likely both oversimplified and wrong. In the first one, a bool then a string is returned which should raise a type error in most cases (unless you do an anonymous function and feed the result back into something that accepts an object-typed parameter/use an object-typed variable to store the result). I don't even know what's up with the second one; that's simply not valid code - if it was a normal function you cannot omit the trailing semicolon, and if it was a anonymous lambda you cannot have a trailing semicolon.