Briefly re: discard — since void is not a proper type like say Unit in Scala, it makes void functions (especially with type parameters) very awkward in general. Adding the additional confusion that you can treat a value-returning function as if it was a void function with discard, and it further destroys clarity of the meaning of types, encouraging developers to shoe-horn side-effectful computation into value-returning procs assuming it will just be used with discard (so there becomes weird convention based designs where you think you’re supposed to use something for its return value, but actually the “intent” is for you to use discard).

Basically, discard & result make Nim a nice language if you are programming alone, and you know & intuitively understand the conventions being used or you can control manually wrapping stuff in Option for a bunch of type signatures or whatever and you can enforce it how you like it.

But when writing code for other people to interact with, the implicit return type initialization creates weird ways of coding around it that are not clear or common sense for other people, and then mixing void and the use of discard makes it super unclear when or why it’s useful to ignore the return type in some context, instead of it having been actually designed as a void function (and for this to have a proper type).

This comment on this Nim issue gives a good example of what I mean, < https://github.com/nim-lang/Nim/issues/7370#issuecomment-376... >.

But generally, I think it just speaks badly of discard-style thinking. Write void functions to communicate side-effectfulness. Don’t mix concerns about a side effect and an optional return value and assume people will get your meaning and know when to use discard. That is more like coding for the function author’s benefit instead of coding for readers, users or other contributors.