4 ms·

> For `result`, the basic description from Nim’s example pages highlights why it’s a severe problem. This is simply an explanation for newcomers. It's really n

by dom96 8y ago

> For `result`, the basic description from Nim’s example pages highlights why it’s a severe problem. 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] You can also use `ref T` and achieve a similar effect: an explicit "empty" state. So there is no weird semi-empty state problem here. 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.

mlthoughts2018 8y ago
This is not a reasonable answer regarding initialization, because you may not want to wrap everything in an Option type. Especially not for an obscure side effect reason like initialization, and then need to litter Option handling all over, which destroys a lot of information in your types. It would be like misusing Maybe in Haskell as if it was for exception handling. You could never write pure functions that get lifted to utilize Maybe. Instead you’d be forcing people to manually use Maybe everywhere, for all signatures. I had also already pointed out the Ref option in my original comment, as an example of exactly the type of anti-pattern that makes it a bad thing you constantly have to code around in 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!
- Araq 8y ago
  That's true and I wouldn't use the Option type for that either. There is a switch that warns about variables that are not initialized explicitly (including the 'result' variable) and an RFC to make this switch non-optional. https://github.com/nim-lang/Nim/issues/7917 https://github.com/nim-lang/Nim/issues/7917
mlthoughts2018 8y ago
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-376168879 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.
- Araq 8y ago
  I'm not following you really. 'discard' is an enforced, explicit statement about that you throw away information/the result of a computation. That's against "nice if you are programming alone" as much as it can get.
  - mlthoughts2018 8y ago
    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.

by dom96 8y ago

mlthoughts2018 8y ago

This is not a reasonable answer regarding initialization, because you may not want to wrap everything in an Option type. Especially not for an obscure side effect reason like initialization, and then need to litter Option handling all over, which destroys a lot of information in your types. It would be like misusing Maybe in Haskell as if it was for exception handling. You could never write pure functions that get lifted to utilize Maybe. Instead you’d be forcing people to manually use Maybe everywhere, for all signatures. I had also already pointed out the Ref option in my original comment, as an example of exactly the type of anti-pattern that makes it a bad thing you constantly have to code around in 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!

Araq 8y ago
That's true and I wouldn't use the Option type for that either. There is a switch that warns about variables that are not initialized explicitly (including the 'result' variable) and an RFC to make this switch non-optional. https://github.com/nim-lang/Nim/issues/7917 https://github.com/nim-lang/Nim/issues/7917

mlthoughts2018 8y ago

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-376168879 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.

Araq 8y ago
I'm not following you really. 'discard' is an enforced, explicit statement about that you throw away information/the result of a computation. That's against "nice if you are programming alone" as much as it can get.
- mlthoughts2018 8y ago
  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.