-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Rename "Const" trait to "Freeze" #3949
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
Comments
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! |
|
"any what?" not to reject |
so I don't think we need to get rid of |
I am still interested in renaming both |
+1 for renaming The word |
Visiting for triage. Whatever happens, this should be settled by milestone "maturity number 2 - backwards compatible". |
This landed as part of #7451. |
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
bump rustc_tools_util version Fixes rust-lang/miri#3845 by incorporating rust-lang/rust-clippy#13329
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
The text was updated successfully, but these errors were encountered: