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.

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

Rename "Const" trait to "Freeze" #3949

Closed
bblum opened this issue Nov 12, 2012 · 8 comments
Closed

Rename "Const" trait to "Freeze" #3949

bblum opened this issue Nov 12, 2012 · 8 comments
Labels
A-traits Area: Trait system A-typesystem Area: The type system

Comments

@bblum
Copy link
Contributor

bblum commented Nov 12, 2012

The word const currently means three things:

  • &const as a mutability qualifier, supertype of "mut" and "" (immut). Directly analogous to C/C++'s meaning.
  • const x: ty = val; for constant globals. Same as the meaning in C/C++/Java/etc.
  • T: Const as a trait, which indicates "no embedded mutability". Corresponds to nothing in any other language, as far as I know.

I propose we change the third one, and leave the other two as they are. Const doesn't even mean the data is constant (it can be borrowed as mutable). In working on the regions paper, I figured this is always used, conceptually, to indicate a "freezable" data structure -- one which becomes deeply constant only when borrowed from immutably. Let's call it that.

related #3542 #3529

@nikomatsakis
Copy link
Contributor

Copying a comment I accidentally wrote in #3542:

I strongly agree with not having const have so many overloaded meanings. To be honest, I think const-the-mutability-qualifier is the odd man out here, and I would like to change it to something else, but I don't know what (read? too valuable to use as a keyword. mut?? looks funny, can't pronounce it. rd or ro? Eh.). I think there is another issue to this effect. I know @jruderman has raised the issue before (and rightly so).

That said, I think Freeze may not be the right name for the trait we currently call Const. Here is my reasoning: a freezable data structure is one which is based purely on owned data and with no explicit mutable qualifiers. This is currently described by Send Const---the Const captures the lack of mutability qualifiers and the Send captures the "relies purely on owned data". So it seems to me that Freeze, if it exists, should be a "subtrait" of Send and Const.

Now, it is not clear to me whether a trait that means "immutable" is necessary on its own. @pcwalton and I have talked about some ideas for removing pure functions and replacing them with closures with a "Const" bound, so it'd be important then. The best name I can come up for to replace Const is Imm (for Immutable, which seems a touch long), even though it is true that an instance of an Imm type, when placed in a mutable local variable (or other mutable context), is in fact mutable. But somehow NoMut doesn't seem to have the same ring!

@pcwalton
Copy link
Contributor

&any int?

@bblum
Copy link
Contributor Author

bblum commented Nov 13, 2012

"any what?"

not to reject any, but it might also conflict with the any type which I believe is in the far-future plans.

@pnkfelix
Copy link
Member

pnkfelix commented May 2, 2013

  • I believe &const is going away in the future
  • const x: ty = val has been replaced by static x: ty = val

so I don't think we need to get rid of Const as a trait at this point. Closing bug.

@pnkfelix pnkfelix closed this as completed May 2, 2013
@brson
Copy link
Contributor

brson commented May 7, 2013

I am still interested in renaming both Const and Owned

@brson brson reopened this May 7, 2013
@thestinger
Copy link
Contributor

+1 for renaming Const to Freeze

The word Const doesn't really get across the meaning, which is that something can be statically frozen by the compiler (either it inherits mutability, or it's immutable).

@toddaaro
Copy link
Contributor

toddaaro commented Jul 3, 2013

Visiting for triage. Whatever happens, this should be settled by milestone "maturity number 2 - backwards compatible".

@thestinger
Copy link
Contributor

This landed as part of #7451.

oli-obk pushed a commit to oli-obk/rust that referenced this issue May 2, 2020
Implement mismatched_target_os lint

I've extended the check suggested in the issue to all the currently supported operating systems instead of limiting it to `linux` and `macos`, let me know if we want to do this.

Also, I've restored the text `There are over XXX lints ...` in the README as it was matched against by `cargo dev new_lint`.

changelog: Added `mismatched_target_os` lint to warn when an operating system is used in target family position in a #[cfg] attribute

Closes rust-lang#3949
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-traits Area: Trait system A-typesystem Area: The type system
Projects
None yet
Development

No branches or pull requests

7 participants