Decide on name for Freeze

[traviscross]

We still need to pick a name for Freeze (which may still be Freeze) so that we can proceed with:

• [RFC] core::marker::Freeze in bounds rfcs#3633

Thoughts?

cc @rust-lang/lang

@rustbot labels +T-lang +I-lang-nominated

[p-avital]

I'm reiterating my proposal from Zulip: keeping Freeze, and instead giving llvm's freeze a more explicit name. To quote myself from there:

I might just be misunderstanding the docs for the intrinsic, but it feels like it'd translate well to a MaybeUninit::read (as opposed to assume_init_read), or maybe deterministic_read or something alike to avoid it looking simpler than the current assume_init set

[traviscross]

Let's see whether we have consensus to simply call it Freeze.

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• should-be-self-documenting-about-interior-mutability (Decide on name for Freeze #131401 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[joshtriplett]

I'm reiterating my proposal from Zulip: keeping Freeze, and instead giving llvm's freeze a more explicit name. To quote myself from there:

I might just be misunderstanding the docs for the intrinsic, but it feels like it'd translate well to a MaybeUninit::read (as opposed to assume_init_read), or maybe deterministic_read or something alike to avoid it looking simpler than the current assume_init set

I don't know if Freeze is the best name for this trait, but I definitely agree that freeze is not the best name for the the LLVM concept.

[joshtriplett]

@rfcbot concern should-be-self-documenting-about-interior-mutability

I think we should use a name that's self-documenting and evokes the concept of interior mutability in some way.

[Scripter17]

Would Frozen work?

[Amanieu]

I'm partial to the name InteriorImmutable for the Freeze trait (which was actually one of the alternatives listed in the RFC). All of the cell-related documentation already uses the term "interior mutability" and the trait name makes it clear that it means that the type does not contain a cell.

[traviscross]

Stylistically, we don't end trait names with "-able". We have Copy and not Copyable, e.g. We just leaned on this principle in deciding to go with derive(CoercePointee) rather than various "-able" options in:

• Decide on name for derive(SmartPtr) #129104

That is, trait names imply the capability to do the thing named in the trait.

What would be the version of an "interior immutable"-style name that matches that?

[Amanieu]

While "mutable" has a verb form "mutate", there isn't any verb equivalent of "immutable" ("not mutate"?). I would therefore argue for an exception to the -able policy for this specific case since "immutable" very clearly captures what this trait is promising.

An alternative that also captures the concept of interior mutability are might be NoInteriorMutate, but that just looks worse than InteriorImmutable since we're just arbitrarily avoiding the -able suffix.

[hkBst]

Some variants to get the juices going:

• NoInteriorMut / NoInternalMut / InternalNoMut / InternallyNoMut / InteriorNoMut,
• NoInteriorChange / NoInternalChange / InternalNoChange / InteriorNoChange,
• InternalConst / InternallyConst / InteriorConst`,
• NoMut / NoChange
• Changeless
• Constant

[RalfJung]

The "action" this trait lets one do is know that if we do two reads from (pointers derived from) a reference where the pointee has this trait, we will get the same value. I don't know how to make that into a nice trait name...

[traviscross]

What @RalfJung said is why I don't hate Freeze, as we can read it as "has the ability to be frozen when taking a reference to it," where "frozen" here means "will not change".

I.e., inventing some notation, we could imagine the trait as:

trait Freeze {
    fn freeze(&self) -> &frozen Self;
}

[thynson]

Maybe InteriorFreeze or FreezeInterior?

[traviscross]

I could live with FreezeInterior (ed: but probably still prefer Freeze). It has a similar ring to it as what we did with CoercePointee.

[p-avital]

@traviscross I'd prefer Freeze to FreezeInterior, as I don't feel the addition of interior buys any clarity, while it does come at the cost of renaming which would make split resources for people looking it up; but at this point, I'm just ready to go with anything that grabs enough traction to finally get stabilized 🫠

[p-avital]

@traviscross This RFC is becoming stale again, with bike-shedding around the trait's name looking like the main blocker.

Do you think setting a deadline on the decision of naming (and possibly a poll with some of the existing options) could help push forward?

[traviscross]

It's a good point. We just need to allocate some time for it in a meeting and commit to the bikeshed. There's a meeting in mid December we have scheduled that would probably make sense for that.