Optionals

[flaviut]

Based heavily on #2515, but lots of stuff is ripped out and modified.

Contents:

• The following procedures: some, none, isSome, isNone, get, unsafeGet, ==
• The Option[T] type
• tests using the unittest module
• updated tutorial

This PR is purposely kept very simple in order to avoid bikeshedding and to get it merged. The reasoning is that new things can always be added in future PRs, removing functionality is much more difficult.

[flaviut]

/cc @dom96 @Araq @bluenote10

[dom96]

Ready to be merged as far as I'm concerned.

One small issue that I have is the use of FieldError, might be a good idea to introduce a custom exception object for this? (This can be done in the future easily though).

So yeah. Once @Araq is happy with it we can merge it.

[flaviut]

I didn't notice the FieldError. I don't think that's a good idea as FieldError seems to be intended for use by the compiler. Perhaps a subtype of ValueError would be more appropriate?

[dom96]

Yeah. Sounds good.

[dom96]

I am also wondering whether we are now encouraging the use of typedesc as a param, none[int]() isn't as nice as none(int) but it is another thing to teach users of Nim. I suppose we were doomed into doing that as soon as this feature was implemented though so we may as well embrace it.

[flaviut]

@dom96 good point re. typedesc. Maybe none[int] will work in the future, but none[int]() is the best solution for now.

[bluenote10]

Yes, this is looking good. The only thing I would add is the implementation of $:

proc `$`*[T](o: Option[T]): string =
  ## Converts to string: `"some(value)"` or `"none(type)"`
  if o.isSome:
    "some(" & $o.val & ")"
  else:
    "none(" & T.name & ")"

From a foreign module, any attempt like this

import optionals
echo some(1)

currently leads to lib/system.nim(2068, 17) Error: undeclared identifier: 'val'. This is because it calls the generic implementation of $, which just iterates over fieldPairs without checking if the fields are public*.

Just out of curiosity: What is wrong with none(T: typedesc)? I didn't know that this is discouraged. I rather considered it already idiomatic because I have seen it frequently. It looks like having defined both none versions can cause trouble, so I would actually not provide none[T]() at all, and go for the nicer version right away?

(*) I came upon this issue before and noticed that a simple when compiles($value) within the loop fixes the problem. Good enough for a PR?

[dom96]

(*) I came upon this issue before and noticed that a simple when compiles($value) within the loop fixes the problem. Good enough for a PR?

Please create a PR for this anyway. I wouldn't want this to get lost in the noise of this discussion.

---

I agree with @bluenote10, let's add $.

In regards to none(T: typedesc), I think it's more consistent with some[T](val) to use none[T]().

[bluenote10]

In regards to none(T: typedesc), I think it's more consistent with some[T](val) to use none[T]().

It is inconsistent on call-site anyways, since nobody will write some[int](1). Imho some(1) and none(int) would match very well.

[dom96]

hrm. Good point.

[flaviut]

Ok, done.

[dom96]

Why did you close this?

[flaviut]

Looks like I accidentally deleted the branch in my repo. Sorry about that!

[reactormonk]

So favor this PR over #2515?

[dom96]

Yep.

[refi64]

I liked the Maybe names better...

[oprypin]

Please remove me as the author. Nothing that remains in this pull request was my idea.

By the way, I would hate using such a module. Absence of "get-or-default" is preposterous.

[dom96]

@BlaXpirit We can add that later.

[flaviut]

@BlaXpirit
Done. You are still listed as the author of 32ebcfa, but that's because those are your commits, squashed.

[oprypin]

I disagree with some removals, but that's OK.
I just can't imagine any reason for removing `$`.

Probably time to merge.

[Araq]

What's a "just"? ;-)

[flaviut]

Fixed.

[ozra]

Ok, shedding time..
maybe sounds much better to me than "option". But regarding some/none vs Haskellish "just.." the 'some'-style sounds much better.

Get-or-default kind of is a must-have when juggling with maybes.

[flaviut]

Get-or-default kind of is a must-have when juggling with maybes.

That's not really controversial. The controversial part is what exactly the syntax for them should be.