RFC: Imply Option #2180

Dynisious · 2017-10-18T06:17:34Z

My RFC for adding some function implementation for the Option type akin to the implies or -> operation from predicate logic. Useful for getting rid of boiler plate code and making the programmers intention clear in their code.

Updated Introduction
The conversation has been going on and things have changed in the specification; I have created a more appropriate introduction further down but left this one unchanged to keep the context of the earlier conversation.

My RFC for adding some function implimentation for the Option type akin to the `implies` operation from predicate logic.

Formatted poorly displayed code and pseudo-code to display correctly and be legible.

SimonSapin · 2017-10-18T08:58:42Z

I am not familiar with predicate logic. Can this RFC be described as “add a pair of constructors to Option that are based on a boolean”? This does sound useful, I’ve sometimes written code that this would have made simpler.

Dynisious · 2017-10-18T09:09:07Z

Yes @SimonSapin that is the idea in layman's terms. "If some boolean is true I want this value (Some(x)) but if this boolean is false throw it away (None)."

petrochenkov · 2017-10-18T09:35:30Z

This would be a useful addition, but I'd personally want to see it as a method on bool.

// These methods are just copied from `Option`
impl bool {
    fn xxx<T>(self, b: T) -> Option<T>; // This one is missing on `Option`
    fn map<T, F>(self, f: F) -> Option<T>  where F: FnOnce() -> T;
    fn and<T>(self, optb: Option<T>) -> Option<T>;
    fn and_then<T, F>(self, f: F) -> Option<T>  where F: FnOnce() -> Option<T>;
}

let my_opt_value = my_bool.xxx(get_value());
let my_opt_value = my_bool.map(|| get_value());
let my_opt_value = my_bool.and(get_opt_value());
let my_opt_value = my_bool.and_then(|| get_opt_value());

oli-obk · 2017-10-18T12:02:32Z

Previous discussion on internals: https://internals.rust-lang.org/t/bool-into-option-closure-yields-none-or-some-closure/1729

The general consensus seemed to be to use the boolinator crate

Centril · 2017-10-18T13:46:24Z

@petrochenkov While I agree they should be methods on bool... The name and_then feels like a monadic >>= (bind), which isn't optimal, since self : bool... tho I get viewing bool as Option<()> which is why reusing the method names on Option is compelling. I'm torn... :(

eddyb · 2017-10-18T13:53:11Z

type bool = Option<()>; would've been an interesting decision if done early on.
That or involving homotopy (with Result<(), ()> too) but that's an active area of research.

Centril

Typos & such improvements (mostly)

Centril · 2017-10-18T13:47:33Z

text/0000-imply-option.md

+# Motivation
+[motivation]: #motivation
+
+This addition will increase the legability of code segments and assist in defining the thought processes and motivations of programmers through code. The use cases of this addition are solutions which are expressable in the following predicate form:


legability -> legibility.

Centril · 2017-10-18T13:48:09Z

text/0000-imply-option.md

+        None
+    }
+```
+The outcome of this addition will reduce repeated code which introduces bugs during refactoring and present the thought process of the programmer in a clearer fasion through their code.


fasion -> fashion

Centril · 2017-10-18T13:49:02Z

text/0000-imply-option.md

+
+The `Option` type is extremely useful when your code may or may not yield a return value.
+Such code may looks similar to this:
+```


extremely useful is probably true, but also too much. useful is probably sufficient.

Centril · 2017-10-18T13:50:06Z

text/0000-imply-option.md

+```
+But the `else` branch is required for returning `None` value if `x == 0` evaluates to false.
+Fortunately Rusts `Option` type has functionality get rid of the unecessary code:
+```


Missing a to between functionality and get.

Centril · 2017-10-18T13:51:56Z

text/0000-imply-option.md

+
+    Option::on_pred(x == 0, x)
+```
+This code performs the exact same function as our original `if` statement however our code is compressed to a single line and our intentions are just as clear.


Change to: "This code has the exact same behaviour as our original if statement. Our code is however compressed to a single line and our intentions are just as clear."

Centril · 2017-10-18T13:57:46Z

text/0000-imply-option.md

+        }
+    }
+```
+This implementation covers the use cases I've proposed in my earlier examples and any others of similar form without any external dependancies; this should make the implementation stable as Rust continues to develope.


dependancies -> dependencies

depersonalize

develope -> develop

Centril · 2017-10-18T14:01:03Z

text/0000-imply-option.md

+# Drawbacks
+[drawbacks]: #drawbacks
+
+This is a functionality which has functional programming and monads in mind with its design and this may make it another stepping stone to be learned for programmers which are new to Rust or functional programming concepts.


Rust already has a lot of FP concepts and actual monadic bind in Option::and_then, Iterator::flat_map in libcore - I don't see why adding a small addition like this would be anything new FP-wise.

I'm not saying it would be anything new, rather it would be just one more little thing which needs to be learned when considering new programmers.

Centril · 2017-10-18T14:02:22Z

text/0000-imply-option.md

+# Rationale and alternatives
+[alternatives]: #alternatives
+
+The implementation I've proposed is clear and easily documented and is the minimal ammount of code and change necessary to add this into the Rust language without sacrificing any of the advantages of the `if/else` blocks.


Depersonalize

Centril · 2017-10-18T14:03:27Z

text/0000-imply-option.md

+    Option::lazy_pred(true, || x)
+```
+It is very little boiler plate code compared to the `if/else` alternative but it is suboptimal from an execution standpoint and a more obtuse implementation for new Rust programmers to learn.
+- Not including the `lazy_pred` function. However, as discussed, this leaves the `on_pred` function at a disadvantage when the equivilant `if` block is computationally intesive as it wastes computation on a value which may simply be discarded.


equivilant -> equivalent

Centril · 2017-10-18T14:04:45Z

text/0000-imply-option.md

+```
+It is very little boiler plate code compared to the `if/else` alternative but it is suboptimal from an execution standpoint and a more obtuse implementation for new Rust programmers to learn.
+- Not including the `lazy_pred` function. However, as discussed, this leaves the `on_pred` function at a disadvantage when the equivilant `if` block is computationally intesive as it wastes computation on a value which may simply be discarded.
+- Providing syntax support for this implementation in Rust (similar to the `?` operator for the `Result` type). However I argue that pushing the abstraction of the logic this far reduces the clarity of the code and the expression of the programmers intention. Additionally discussion has yet to addiquately cover syntax support for both the `on_pred` and `lazy_pred` functions in a meaningful manner and removing either one is disadvantages as discussed above.


addiquately -> adequately

disadvantages -> disadvantageous

Centril · 2017-10-18T14:13:11Z

@eddyb and const true: Option<()> = Some(()); const false: Option<()> = None;. Yeah, let's do HoTT in 15 years ;)

est31 · 2017-10-18T17:03:36Z

"I’ve sometimes written code that this would have made simpler." is IMO not a good argument to add a completely new operator to the language. It needs to be used really really often for that to be the case. If there is one special area where the code would benefit from it, just define a macro.

Centril · 2017-10-18T17:22:08Z

@est31 Was an actual operator proposed (with sigils and stuff...) or just a method? The bar for the former is of course significantly higher. But the bar is still high for methods.

SimonSapin · 2017-10-18T17:26:52Z

It’s a methods. (Or rather, two.)

@Centril

Fixed some spelling errors spotted by @Centril

Dynisious · 2017-10-18T20:54:46Z

I do feel that @est31 has a point in saying that a macro could be the appropriate measure to take (I do often forget about macros). An implementation such as the following could possibly be better:

macro_rules! on_pred {
    ($pred:expr, $result:expr) => (
        if $pred {
            Some($result)
        } else {
            None
        }
    )
}

This has the additional benefits of being inherently lazy, eliminating the need for a separate lazy_pred, if I understand how macros evaluate expressions correctly, else a lazy_pred macro would be trivial.
However, I do feel that abstracting this away into a macro loses the explicitness of a constructor:

Option::on_pred(x == 0, x) //It is very clear here that I am constructing an `Option` type.
on_pred!(x == 0, x) //May be functionally identical but is less explicit and informative about what exactly is being done.

est31 · 2017-10-18T21:55:30Z

@SimonSapin @Centril @Dynisious oh sorry, I've only skimmed the proposal and got confused a little. Disregard my comment then! Adding a method is entirely reasonable. 👍

eddyb · 2017-10-18T22:00:44Z

@Centril Yeah, I was implying those definitions for true and false. We could do that now (with rust-lang/rust#45225 Option<()> is literally represented the same way bool is) but it would break any code that implemented a trait for both Option and bool.

Centril · 2017-10-18T22:14:00Z

@eddyb That sounds like a non-starter ;)

scottmcm · 2017-10-19T01:40:38Z

Could the syntax for on_pred!(p, r) literally just be if p { r }? (Or maybe if p { Some(r) }.)

Strawman proposal for the latter:

Change the desugar from if A { B } => if A { B } else { () }
to if A { B } => if A { B } else { Default::default() }.
Existing code has typeof(B) == (), and unit has a unit default, so existing things (mostly) work.
For new things like let z = if x != 0 { Some(x) };, the type comes from the block.

Improvement opportunities for the strawman:

This would break inference in some cases, like if p { Default::default() }. I think that's an allowed break, but practicality would of course depend on the actual impact of such a thing.
Using straight Default might not be the best choice, since as described it means if x != 0 { x } is equivalent to just x. A different (possibly forever-unstable) trait that produces either () or Try::from_error(Default::default()) might be a more reasonable restriction.
Making it be if p { r } would require something like ok-wrapping, for better or worse.

Non-serious proposal for the bool <=> Option<()> discussion:

struct False;
struct True;
impl ops::Try for bool {
    type Ok = True;
    type Error = False;
    fn into_result(self) -> Result<True, False> {
        if self {
            Ok(True)
        } else {
            Err(False)
        }
    }
    fn from_ok(_: True) -> Self { true }
    fn from_error(_: False) -> Self { false }
}

Dynisious · 2017-10-19T02:04:39Z

@oli-obk I have looked into the boolinator crate after you've mentioned it and I do recognise the similarities. However, the discussion here is about implementing similar functionality in the standard rust libraries; if the consensus of the community is that the full implementation of boolinator should be included in the standard libraries then that can go ahead but I doubt that will be the case. boolinator adds several functions, such as as_option or ok_or, which do not have wide enough applications to be included as standard in my opinion.

Dynisious · 2017-10-19T02:19:20Z

@petrochenkov Implementing this functionality as methods on bool rather than as constructors for Option is an interesting suggestion though I don't intuitively see the advantage gained by this change.
Additionally the and and and_then methods you've suggested don't seem to lend anything extra to the language verses:

let return_value = my_bool.xxx(my_value).and(option_value)
let return_value = my_bool.xxx(my_value).and_then(|| option_value)
let return_value = my_bool.map(|| my_value).and(option_value)
let return_value = my_bool.map(|| my_value).and_then(|| option_value)

leoyvens · 2017-10-19T18:36:51Z

It seems better to just add From<bool> for Option(()) and piggyback on the Option methods, example:

my_bool.into().map(|_| my_value)

I don't think you need an RFC to add that impl just a PR with a final comment period.

Centril · 2017-10-19T21:18:44Z

@leodasvacas I think that From<bool> for Option(()) should be added irrespective of merging this RFC or not. However, .into().map(|_| myvalue) seems more wordy compared to a more direct approach.

petrochenkov · 2017-10-19T21:23:06Z

my_bool.into().map(|| my_value)

I'm pretty sure this won't pass type inference.

leoyvens · 2017-10-20T00:04:41Z

My suggestion was mistaken, ~~we don't need a new impl we already have~~ such an impl would conflict with From<T> for Option<T>, and inference can't figure it out anyways as @petrochenkov said.

I can restate my sugestion as adding a method to bool that would make the conversion, such as fn optionalize(self) -> Option(()). Even that long name is the same length as the RFC proposal.

my_bool.optionalize().map(|_| value)
Option::lazy_pred(my_bool, |_| value)

Dynisious · 2017-10-22T09:34:04Z

I agree that it could be advantageous to convert bool to Option<()> rather than constructing an Option<T> on a bool; from my understanding it would evaluate in a functionally identical manner to my original constructor suggestions with the advantage of applying currying to the implementation.

Centril · 2017-10-25T04:50:25Z

@leodasvacas .optionalize() is a bit long... how about .iso() for isomorphism?

ssokolow · 2017-10-25T06:42:24Z

@Centril .iso() is not intuitive enough and I'm willing to bet a lot of programmers who did discover it would wind up having to re-consult the manual a few times before it sticks.

...both because "isomorphism" is a very jargon-y word that I'd actually never heard before (and I've been programming in languages no more functional than Python for over 15 years) and because abbreviating it to "iso" is like having a crate named "api-binding". There are simply too many things "iso" could be short for.

scottmcm · 2017-12-10T08:38:23Z

What do you think about generalizing for Try?:

The usual problem with generalizing the return type to a generic is that it needs to be inferred from context. my_bool.bikeshed_me(|| foo()).map(bar) wouldn't compile.

For this case specifically, the strawman posted wouldn't even work with Option, since there's no () -> NoneError conversion through Into. I suppose it could be generalized to E: Default or something, but really I prefer just supporting Option, as a perfectly reasonable representation of "you only provided my the success value". There's always ok_or and friends if they really wanted a Result (and didn't just use an if), and the usual interconversion rules of ? are there if that was desired.

Centril · 2017-12-10T18:11:32Z

@scottmcm Fair enough =)

Added the Legal Double Reference RFC.

JustAPerson · 2018-03-23T06:47:12Z

I think adding the methods on the bool impl would be great. Definitely have wanted this in the past.

This RFC's title seems very misleading however.

varkor · 2018-05-27T16:46:44Z

What's the status of this RFC? I've often wanted similar functionality — is the main blocker here deciding upon method names?

aturon · 2018-06-03T18:59:04Z

I'm unassigning myself and nominating for libs team discussion.

nielsle · 2018-06-03T20:45:48Z

Just for completeness. The following works on nightly.

let pred = true;
let filtered = Some("test").filter( |_| pred );

jonhoo · 2018-06-03T22:29:19Z

@nielsle I don't think that quite covers the use-case. Specifically, consider the case where the Some is expensive to construct. You would much rather do

pred.if_true(|| make_expensive_thing())

Dynisious · 2018-06-14T06:06:22Z

Hey been a while since I did anything with this.
Finally got around to making a simple crate implementation

alexcrichton · 2018-08-23T18:16:50Z

@rfcbot fcp postpone

This RFC is unfortunately a little old at this point and has languished for awhile. At this point I think it's clear that we don't have the bandwidth or motivation at this point to push the bikeshed here to completion to figure out what names these methods would have in the standard library. In the meantime there's a crate on crates.io for these methods which isn't great in terms of ergonomics but provides a good way to test out the eventual method names!

I propose we postpone this RFC to a later date when the bikeshed can be driven to completion. Otherwise we're not necessarily benefitting much from having this RFC bake in the queue.

rfcbot · 2018-08-23T18:16:50Z

Team member @alexcrichton has proposed to postpone this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

rfcbot · 2018-09-05T17:48:01Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2018-09-15T17:48:03Z

The final comment period, with a disposition to postpone, as per the review above, is now complete.

By the power vested in me by Rust, I hereby postpone this RFC.

varkor · 2019-09-05T11:33:34Z

I've opened a follow up RFC here: #2757.

Imply Option

d7e0c0d

My RFC for adding some function implimentation for the Option type akin to the `implies` operation from predicate logic.

Dynisious changed the title ~~Imply Option~~ RFC: Imply Option Oct 18, 2017

Formatting

71adf99

Formatted poorly displayed code and pseudo-code to display correctly and be legible.

Centril reviewed Oct 18, 2017

View reviewed changes

withoutboats added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Oct 18, 2017

Spelling Corrections

99ec896

Fixed some spelling errors spotted by @Centril

Dynisious added 2 commits December 27, 2017 20:57

RFC Legal Double Reference

c87c398

Added the Legal Double Reference RFC.

Delete 0000-legal-double-reference.md

d9c9a08

aturon self-assigned this Jan 23, 2018

kennytm mentioned this pull request May 8, 2018

Mapping booleans to Option rust-lang/rust#50523

Closed

aturon removed their assignment Jun 3, 2018

aturon added the I-nominated label Jun 3, 2018

rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-postpone This RFC is in PFCP or FCP with a disposition to postpone it. labels Aug 23, 2018

rfcbot added the final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. label Sep 5, 2018

rfcbot removed the proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. label Sep 5, 2018

rfcbot closed this Sep 15, 2018

petrochenkov mentioned this pull request Dec 5, 2018

Idea: Built-in way to go from bool to Option #2606

Closed

varkor mentioned this pull request Sep 5, 2019

Add methods for converting from bool to Option<T> #2757

Closed

RFC: Imply Option #2180

RFC: Imply Option #2180

Conversation

Dynisious commented Oct 18, 2017 • edited Loading

SimonSapin commented Oct 18, 2017

Dynisious commented Oct 18, 2017

petrochenkov commented Oct 18, 2017

oli-obk commented Oct 18, 2017

Centril commented Oct 18, 2017

eddyb commented Oct 18, 2017

Centril left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Centril commented Oct 18, 2017

est31 commented Oct 18, 2017

Centril commented Oct 18, 2017

SimonSapin commented Oct 18, 2017

Dynisious commented Oct 18, 2017 • edited Loading

est31 commented Oct 18, 2017

eddyb commented Oct 18, 2017

Centril commented Oct 18, 2017

scottmcm commented Oct 19, 2017

Dynisious commented Oct 19, 2017

Dynisious commented Oct 19, 2017

leoyvens commented Oct 19, 2017 • edited Loading

Centril commented Oct 19, 2017

petrochenkov commented Oct 19, 2017

leoyvens commented Oct 20, 2017 • edited Loading

Dynisious commented Oct 22, 2017

Centril commented Oct 25, 2017

ssokolow commented Oct 25, 2017

scottmcm commented Dec 10, 2017

Centril commented Dec 10, 2017

JustAPerson commented Mar 23, 2018

varkor commented May 27, 2018

aturon commented Jun 3, 2018

nielsle commented Jun 3, 2018 • edited Loading

jonhoo commented Jun 3, 2018 • edited Loading

Dynisious commented Jun 14, 2018 • edited Loading

alexcrichton commented Aug 23, 2018

rfcbot commented Aug 23, 2018 • edited by withoutboats Loading

rfcbot commented Sep 5, 2018

rfcbot commented Sep 15, 2018

varkor commented Sep 5, 2019

Dynisious commented Oct 18, 2017 •

edited

Loading

Dynisious commented Oct 18, 2017 •

edited

Loading

leoyvens commented Oct 19, 2017 •

edited

Loading

leoyvens commented Oct 20, 2017 •

edited

Loading

nielsle commented Jun 3, 2018 •

edited

Loading

jonhoo commented Jun 3, 2018 •

edited

Loading

Dynisious commented Jun 14, 2018 •

edited

Loading

rfcbot commented Aug 23, 2018 •

edited by withoutboats

Loading