Skip to content

Add implementation on Option is confusing #8127

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Kimundi opened this issue Jul 30, 2013 · 3 comments
Closed

Add implementation on Option is confusing #8127

Kimundi opened this issue Jul 30, 2013 · 3 comments

Comments

@Kimundi
Copy link
Member

Kimundi commented Jul 30, 2013

Right now add on two Options effectively treats a None as a Some(Zero::zero()), which is:

  • Unnecessary because Some(Zero::zero()) is already a valid value, why duplicate it's meaning with None?
  • Contrary to the way the Maybe Monad in Haskell works: If both values are a Some, add them, else return None.
@bstrie
Copy link
Contributor

bstrie commented Jul 30, 2013

I think this might be a dup of #6002, but what does this have to do with Zero::zero()?

@Kimundi
Copy link
Member Author

Kimundi commented Jul 30, 2013

@bstrie: Maybe I expressed it strange :)

What I mean is: If the implementation is such that Some(n) + None = Some(n), then None becomes then additive neutral element for, eg Option<uint>. But that is unnecessary because Option<uint> already has a additive neutral element: Some(0). A None is a separate value from any other Some(n), If you treat it the same as Some(0) you might as well not have an Option-value at all.

My talk about Zero::zero() was just an attempt to talk about the generic additive neutral element. :)

@Kimundi
Copy link
Member Author

Kimundi commented Jul 30, 2013

Anyway, this is indeed a duplicate of that issue, closing this one.

@Kimundi Kimundi closed this as completed Jul 30, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Dec 30, 2021
@bors
Auto merge of rust-lang#8127 - dswij:8090, r=xFrednet
56ccd30 
Fix `enum_variants` FP on prefixes that are not camel-case

closes rust-lang#8090

Fix FP on `enum_variants` when prefixes are only a substring of a camel-case word. Also adds some util helpers on `str_utils` to help parsing camel-case strings.

This changes how the lint behaves:

1. previously if the Prefix is only a length of 1, it's going to get ignored, i.e. these were previously ignored and now is warned
```rust
enum Foo {
    cFoo,
    cBar,
    cBaz,
}

enum Something {
    CCall,
    CCreate,
    CCryogenize,
}
```

2. non-ascii characters that doesn't have casing will not be split,
```rust
enum NonCaps {
    PrefixXXX,
    PrefixTea,
    PrefixCake,
}
```
will be considered as `PrefixXXX`, `Prefix`, `Prefix`, so this won't lint as opposed to fired previously.

changelog: [`enum_variant_names`] Fix FP when first prefix are only a substring of a camel-case word.

---

 (Edited by `@xFrednet` removed some non ascii characters)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bstrie @Kimundi