[mlthoughts2018]

Huh? What does it’s status as an explicit language construct have to do with the situations when it’s useful for design?

I’m saying when you program alone, you know when to use discard on your otherwise value-returning function. Other people don’t, and the use of the return type actually suggests the opposite. That you should intentionally invoke that proc for its return value.

> “That's against "nice if you are programming alone" as much as it can get.”

I don’t understand this claim. Nothing about the formal definition of a language is for or against being “nice if you program alone” — rather it is what patterns of usage does it encourage or facilitate.

It’s like “C++ without exceptions”. The formal implementation is just some factoid of the language, but the usage that arises around discard is a bad anti-pattern in terms of communicating intended usage and whether / when to rely on side-effects.

[Araq]

I agree that 'discard' is usually a code smell, but how would implicitly ignoring the result be any better? It wouldn't be better at all, and that means Nim's discard feature is rather well designed as it improves the status quo.

[mlthoughts2018]

Why is implicitly ignoring the result the option you’re comparing with? Instead, create language features that encourage you to separate side-effectful functions from value-returning ones.

Also many languages use a very standard convention of assigning underscore to parts of a result value to be ignored, and discard has no clear advantages over this in my mind.