Option

[tttardigrado]

Improve the Option implementation by adding the following functions:

• FromPtr: Lifts a pointer into an Option
• ToPtr: "Unlifts" an Option into a pointer
• IsSomeAnd: Check if the Option has a value and if that value satisfies a predicate
• Filter: Apply a predicate to the Option value if it exists and return Some on true and None on false
• Flat: Remove one level of nesting from an Option: Option[Option[T]] -> Option[T]

I also added tests for these new features and a mention in the Readme

[codecov]

Codecov Report

Merging #7 (bbf152d) into main (1684a67) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main        #7   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           11        11           
  Lines          119       139   +20     
=========================================
+ Hits           119       139   +20     

Impacted Files	Coverage Δ
option/option.go	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[tttardigrado]

The last commit should fix the issue #8

[tttardigrado]

Also implemented the Get function
It panics if the Option given as an argument is None, but sometimes we are sure that the Option is Some (for example using IsNone and IsSome) and Get becomes easier to use and read than GetOrElse

[repeale]

hello @Force4760,

thanks again, couple inline comments:

Improve the Option implementation by adding the following functions:

• FromPtr: Lifts a pointer into an Option
• ToPtr: "Unlifts" an Option into a pointer

I have some doubts on this if it's something inline with functional principles as the end result might be changed by some external code changing the value the pointer is pointing to. Do you have further examples of something similar in Scala or fp-ts? Would be really useful to understand how that could be used in the future.

• IsSomeAnd: Check if the Option has a value and if that value satisfies a predicate

i think we should rename it as exists check here

• Filter: Apply a predicate to the Option value if it exists and return Some on true and None on false

LGTM we might also check fp-ts for ref

• Flat: Remove one level of nesting from an Option: Option[Option[T]] -> Option[T]

LGTM i would just split the implementation in another PR and rename it as flatten to be more inline with Scala and fp-ts

I also added tests for these new features and a mention in the Readme

On the Get implementation i think it is not inline with functional principles of throwing exceptions. I think we should leverage to GetOrElse only. Can i get more context on which would be a good use case?

I will keep the PR open to discuss the various points but would be great to separate in other smaller PRs code that it's ok to be merged.

[tttardigrado]

Pointers

I haven't seen anything similar neither in fp-ts nor scala (I don't think TS has pointers)

Pointers are, in some way, an unsafe version of option

• nil <-> None
• &x <-> Some(x)

The idea behind FromPtr and ToPtr is for them to serve as a kind of "bridge" between the unsafe and impure world of pointers and the safe and pure world of options.

Even if we want to keep everything pure, some other important/popular go modules use pointers, so it would be needed to have some kind of bridge between options and pointers.

Get

The use of Get can be a way to simplify code. Here's an example

func ZipWith(f func(A, B) C, oA Option[A], oB Option[B]) Option[C] {
    if isSome(oA) && isSome(oB) {
        // Because of the `if statement` we are sure that `Get` will not panic
        return Some( f( Get(oA), Get(oB) )
    }
    return None[C]
}

Name changes

No problem at all :)