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

self should be a keyword #4176

Closed
pcwalton opened this issue Dec 13, 2012 · 10 comments
Closed

self should be a keyword #4176

pcwalton opened this issue Dec 13, 2012 · 10 comments
Labels
A-grammar Area: The grammar of Rust

Comments

@pcwalton
Copy link
Contributor

Contextual right now; needs to be a real keyword.
@cpeterso cpeterso mentioned this issue Jan 18, 2013
Closed
@sonwow
Copy link
Contributor

sonwow commented Jan 25, 2013

I'm working on this issue.

@sonwow
Copy link
Contributor

sonwow commented Feb 4, 2013

In my opinion, if self is converted to a keyword it is impossible to use self keyword to function name, trait name and module name. Is there anything else? Please let me know your opinion about this.

@graydon
Copy link
Contributor

graydon commented Feb 4, 2013

The intent of this bug (which I concur with) is for self to be usable only as the name of the self-parameter in methods, and possibly the lifetime associated with that parameter.

In any case, it's fine by me -- fitting with the purpose of this bug -- if we lose arbitrary additional contexts for its use (function names, trait names, module names, etc.)

@z0w0
Copy link
Contributor

z0w0 commented Feb 16, 2013

I'm pretty sure this is done now.

@catamorphism
Copy link
Contributor

Is this done? I can't find the commit that fixes it.

@sonwow
Copy link
Contributor

sonwow commented Feb 18, 2013

As far as I know, this is not done. If you want to do this issue, please comment here and do that.

@brson
Copy link
Contributor

brson commented Mar 31, 2013

Not 0.6

@sanxiyn
Copy link
Member

sanxiyn commented May 3, 2013

Nominating for backwards compatible milestone.

@graydon
Copy link
Contributor

graydon commented May 9, 2013

accepted for backwards-compatible milestone

@pcwalton
Copy link
Contributor Author

Fixed.

flip1995 pushed a commit to flip1995/rust that referenced this issue Dec 6, 2020
@bors
Auto merge of rust-lang#6421 - xFrednet:4176-unreadable-literal-lint-…
c1664c5 
…fractal-option, r=Manishearth

Added a lint-fraction-readability flag to the configuration

This adds an option to disable the `unreadable_literal` lint for floats with a longer fraction. This allows users to write `0.100200300` without getting a warning. Fixes rust-lang#4176

I have some open questions about this PR:
1. I've named the option `lint-fraction-readability` is this a good name or should I rename it to something else?
2. What should the default configuration value be?
    * The current default value is `true` as this was also the previous default.
3. Do I have to document this new option somewhere else or will it be extracted from the code comment?
4. The current fix option will also rewrite the fraction if the integer part violates the `unreadable_literal` lint it would otherwise also trigger the `inconsistent_digit_grouping` lint. Is this also okay?
    * `1.100200300` will be unaffected by the fix function
    * `100200300.100200300` will be effected and fixed to `100_200_300.100_200_300`

---

The project needed some getting used to but I'm happy with the result. A big thank you to `@flip1995` for giving me some pointers for this implementation and to everyone for the great introduction documentation!

---

changelog: Added the `unreadable-literal-lint-fractions` configuration to disable the `unreadable_literal` lint for fractions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-grammar Area: The grammar of Rust
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@graydon @sanxiyn @brson @pcwalton @catamorphism @z0w0 @sonwow