[Merged by Bors] - style: prefer some/none over .some/.none#27896
[Merged by Bors] - style: prefer some/none over .some/.none#27896JovanGerb wants to merge 5 commits intoleanprover-community:masterfrom
some/none over .some/.none#27896Conversation
PR summary f0f1d7c49bImport changes for modified filesNo significant changes to the import graph Import changes for all files
Declarations diffNo declarations were harmed in the making of this PR! 🐙 You can run this locally as follows## summary with just the declaration names:
./scripts/declarations_diff.sh <optional_commit>
## more verbose report:
./scripts/declarations_diff.sh long <optional_commit>The doc-module for No changes to technical debt.You can run this locally as
|
|
This might need a zulip thread if this is a new style decision, or a pointer to a core style guide if lean itself has already adopted this. I'm been bitten one too many times by |
|
I don't understand what you mean with throws an error. |
|
reassigning to maintainer @eric-wieser since most of the code is in the meta part of the library which I'm not familiar with. |
|
Thanks @JovanGerb, indeed I must have been remembering the behavior of @kmill, do you know if core has a preference here? |
|
This pull request has conflicts, please merge |
|
This pull request has conflicts, please merge |
|
@eric-wieser I don't think core has any advice, though |
|
bors r+ |
The notation `.some` and `.none` are very useful when working with other inductive types such as `LOption` which have fields names `some` and/or `none`. But for `Option`, we prefer to simply write `some`/`none`. [#mathlib4 > style: `.some`/`.none` vs `some`/`none`](https://leanprover.zulipchat.com/#narrow/channel/287929-mathlib4/topic/style.3A.20.60.2Esome.60.2F.60.2Enone.60.20vs.20.60some.60.2F.60none.60) Co-authored-by: Jovan Gerbscheid <jovan.gerbscheid@gmail.com>
|
Pull request successfully merged into master. Build succeeded: |
some/none over .some/.nonesome/none over .some/.none
…y#27896) The notation `.some` and `.none` are very useful when working with other inductive types such as `LOption` which have fields names `some` and/or `none`. But for `Option`, we prefer to simply write `some`/`none`. [#mathlib4 > style: &leanprover-community#96;.some&leanprover-community#96;/&leanprover-community#96;.none&leanprover-community#96; vs &leanprover-community#96;some&leanprover-community#96;/&leanprover-community#96;none&leanprover-community#96;](https://leanprover.zulipchat.com/#narrow/channel/287929-mathlib4/topic/style.3A.20.60.2Esome.60.2F.60.2Enone.60.20vs.20.60some.60.2F.60none.60) Co-authored-by: Jovan Gerbscheid <jovan.gerbscheid@gmail.com>
…y#27896) The notation `.some` and `.none` are very useful when working with other inductive types such as `LOption` which have fields names `some` and/or `none`. But for `Option`, we prefer to simply write `some`/`none`. [#mathlib4 > style: &leanprover-community#96;.some&leanprover-community#96;/&leanprover-community#96;.none&leanprover-community#96; vs &leanprover-community#96;some&leanprover-community#96;/&leanprover-community#96;none&leanprover-community#96;](https://leanprover.zulipchat.com/#narrow/channel/287929-mathlib4/topic/style.3A.20.60.2Esome.60.2F.60.2Enone.60.20vs.20.60some.60.2F.60none.60) Co-authored-by: Jovan Gerbscheid <jovan.gerbscheid@gmail.com>
The notation
.someand.noneare very useful when working with other inductive types such asLOptionwhich have fields namessomeand/ornone. But forOption, we prefer to simply writesome/none.#mathlib4 > style: `.some`/`.none` vs `some`/`none`