Skip to content
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

Syntax extension for converting enums to/from integers #3868

Closed
erickt opened this issue Oct 26, 2012 · 9 comments · Fixed by #9250
Closed

Syntax extension for converting enums to/from integers #3868

erickt opened this issue Oct 26, 2012 · 9 comments · Fixed by #9250
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-syntaxext Area: Syntax extensions

Comments

@erickt
Copy link
Contributor

erickt commented Oct 26, 2012

Converting an enum to and from an integer is repetitive and brittle. So instead we should add the traits ToInt/FromInt/ToUint/FromUint, and add a syntax extension to automatically generate implementations of those traits for a given enum.
@nikomatsakis
Copy link
Contributor

+1

@ghost ghost assigned erickt Oct 26, 2012
@graydon
Copy link
Contributor

graydon commented Oct 27, 2012

The 'to' side is currently automatic, foo as uint. The 'from' side is trickier since it has to only consider the valid constructors. In any case, while this is a real problem I do not feel it's best approached via syntax extension. More like an additional dimension of the deriving thing.

@sanxiyn
Copy link
Member

sanxiyn commented Feb 12, 2013

This is #2132?

@erickt
Copy link
Contributor Author

erickt commented Feb 12, 2013

That only captures the ToInt side of things. Trying to convert an integer into an enum can be prone to error because you need to make sure the definition of an enum is sharing the same integer bindings as the conversion code. It's easy to add a new variant and forget to update the converters.

@erickt
Copy link
Contributor Author

erickt commented Feb 12, 2013

Ack, I completely misread #2132. Yes you are right, they are the same. This deriving method @graydon mentioned is the modern way of generating this kind of code.

@graydon
Copy link
Contributor

graydon commented May 1, 2013

I suppose I did not know when I wrote that comment that deriving is implemented as a syntax extension. In that case, yeah, let's merge #2132 with this and say this is just a new deriving mode. Nominating for feature complete.

@graydon graydon mentioned this issue May 1, 2013
Closed
@graydon
Copy link
Contributor

graydon commented May 9, 2013

accepted for feature-complete milestone

@emberian
Copy link
Member

emberian commented Jul 7, 2013

Related to #7080

@catamorphism
Copy link
Contributor

Bug triage. Milestone looks good to me.

@erickt erickt mentioned this issue Sep 17, 2013
Merged
@bors bors closed this as completed in 2733b18 Oct 5, 2013
@erickt erickt removed their assignment Jun 16, 2014
@EPashkin EPashkin mentioned this issue Apr 24, 2016
Merged
@ctz ctz mentioned this issue Sep 2, 2017
Closed
JohnTitor added a commit to JohnTitor/rust that referenced this issue Jan 30, 2021
@JohnTitor
Rollup merge of rust-lang#81501 - calebcartwright:update-rustfmt, r=s…
6090c57 
…anxiyn

update rustfmt to v1.4.34

Short summary: Various formatting fixes (several const generic related) and introduction of `imports_granularity` config option

Long summary copied from changelog:

#### Changed
- `merge_imports` configuration has been deprecated in favor of the new `imports_granularity` option. Any existing usage of `merge_imports` will be automatically mapped to the corresponding value on `imports_granularity` with a warning message printed to encourage users to update their config files.

#### Added
- New `imports_granularity` option has been added which succeeds `merge_imports`. This new option supports several additional variants which allow users to merge imports at different levels (crate or module), and even flatten imports to have a single use statement per item. ([PR rust-lang/rustfmt#4634](rust-lang/rustfmt#4634), [PR rust-lang/rustfmt#4639](rust-lang/rustfmt#4639))

See the section on the configuration site for more information
https://rust-lang.github.io/rustfmt/?version=v1.4.33&search=#imports_granularity

#### Fixed
- Fix erroneous removal of `const` keyword on const trait impl ([rust-lang/rustfmt#4084](rust-lang/rustfmt#4084))
- Fix incorrect span usage wit const generics in supertraits ([rust-lang/rustfmt#4204](rust-lang/rustfmt#4204))
- Use correct span for const generic params ([rust-lang/rustfmt#4263](rust-lang/rustfmt#4263))
- Correct span on const generics to include type bounds ([rust-lang/rustfmt#4310](rust-lang/rustfmt#4310))
- Idempotence issue on blocks containing only empty statements ([rust-lang/rustfmt#4627](rust-lang/rustfmt#4627) and [rust-lang#3868](rust-lang/rustfmt#3868))
- Fix issue with semicolon placement on required functions that have a trailing comment that ends in a line-style comment before the semicolon ([rust-lang/rustfmt#4646](rust-lang/rustfmt#4646))
- Avoid shared interned cfg_if symbol since rustfmt can re-initialize the rustc_ast globals on multiple inputs ([rust-lang/rustfmt#4656](rust-lang/rustfmt#4656))
- Don't insert trailing comma on (base-less) rest in struct literals within macros ([rust-lang/rustfmt#4675](rust-lang/rustfmt#4675))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) A-syntaxext Area: Syntax extensions
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add {To,From}Primitive conversion trait, add #[deriving(FromPrimitive)] for enums erickt/rust
6 participants
@graydon @sanxiyn @erickt @nikomatsakis @catamorphism @emberian