I won't comment on Cython as I haven't personally used it much, but:
> though the language design has some warts with `result` and `discard`, etc.
Why do you consider these to be warts?
> though the language design has some warts with `result` and `discard`, etc.
Why do you consider these to be warts?
< https://nim-by-example.github.io/variables/result/ >
Even just needing to account for that mental gymnastics about declaring a new result variable is, I think, not forgivable.
The bigger issue though is that initialization of the return variable is implicit, which is inherently problematic. This is especially troublesome because type constructors in Nim are essentially always separate factory functions. So you have to remember to manually call a particular constructor or else `result` might be just an improperly initialized skeleton of your data type.
For example, I might have some type called MyType and a proc with return type of MyType. I explicitly don’t want the proc to initialize `result` to an empty MyType behind the scenes, for whatever implementation reasons about MyType (a common example is a type that ought to be initialized with the acquisition of a resource and should never exist in a partially initialized state in which the resource acquisition hasn’t been attempted yet, and could possibly fail later).
If I only want it to be initialized from a special constructor like mkMyType(), then in Nim, I have to code around this limitation by making it a void proc, and passing in an appropriately mutable reference.
In other words, to avoid possibly inappropriate return type initialization, I am forced to revert to poor C-style void functions all over that mutate placeholder inputs by convention, which undermines a lot of things Nim tries to do to improve clarity about pure vs impure procs.
I don’t have time to go into why discard is a bad design idea right now, but hope to come back and add more later.
This is simply an explanation for newcomers. It's really not something that's a "severe problem", just something to be aware of.
> The bigger issue though is that initialization of the return variable is implicit, which is inherently problematic. This is especially troublesome because type constructors in Nim are essentially always separate factory functions. So you have to remember to manually call a particular constructor or else `result` might be just an improperly initialized skeleton of your data type.
This really isn't an issue when you can do this:
import options
type
MyFile = Option[int]
proc getFile(): MyFile =
# Oh no, I didn't initialise it...
discard
echo(getFile()) # -> none[int]
I would really like to hear why you think `discard` is a bad design idea. I honestly cannot even imagine a reason as I consider this to be one of the best features of Nim.
It’s not reasonable to suggest you have to code past this intrinsic limitation everywhere by muddying all your function signatures to take Option types and adding extra logic to pack or unpack values from Option types all over... to solve an initialization problem!
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.
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.
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.