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.

[p-avital]

@traviscross Any timeline to try to get this sorted? The breaking change that pushed the need for this is still a major thorn in stabby's side :(

[traviscross]

No, unfortunately. What I can say is that clearing the backlog of things like this is high on my priority list, and I have some plans about how we might do that.

[p-avital]

Is there any way I can be helpful in the process? :)

[hkBst]

Would it make sense to instead of the trait Freeze, have its negation NoFreeze, expressing the fact that some type does have an UnsafeCell somewhere in its representation, instead of the absence of that? Name could be InteriorMut(ate) or InternalChange or InnerMut(ate) or InnerChange or something like that...

"core::marker::Freeze is a trait that is implemented for any type whose memory layout doesn't contain any UnsafeCell: it indicates that the memory referenced by &T is guaranteed not to change while the reference is live." -- the RFC

[p-avital]

The problem with that is that since you can't make negative bounds, such a trait wouldn't have much use, as its usefulness stands from the particular properties Freeze allows you (or the compiler) to tell about a value.

On the other hand, I've wanted negative bounds for so long that if this bikesheding ends up being the final nail in that coffin, I'd wouldn't even be mad; but I somehow doubt that would happen :D

[traviscross]

Is there any way I can be helpful in the process? :)

We may need a design meeting to resolve this, and for that we'll need a design document that collects the options that have been proposed and the arguments that have been made about them and then proposes a plan. If you could put that together, it'd help. I'll reach out separately about this on Zulip.

[bstrie]

Given that the major caveat of this trait is that it only implies immutability up until some form of indirection, I'm surprised that nobody has proposed Direct as a component of a potential name. Something like DirectFreeze or DirectlyImmutable seem natural and accurate to me.

Aside, one of the reasons that I don't like InteriorFreeze or any use of the word "interior" is that, even if these types prevent interior mutability, they do not prevent interior interior mutability, which seems liable to be surprising. (EDIT: although this objection goes away if we adopt the Direct terminology above, e.g. NoDirectInteriorMutability, to emphasize that we don't cover the case of transitive interior mutability.)

[hkBst]

I wanted to brain storm a little about what action this trait enables, so I went back to the RFC:

"Orthogonally to static-promotion, core::marker::Freeze can also be used to ensure that transmuting &T to a reference to an interior-immutable type (such as [u8; core::mem::size_of::<T>()]) is sound (as interior-mutation of a &T may lead to UB in code using the transmuted reference, as it expects that reference's pointee to never change). This is notably a safety requirement for zerocopy and bytemuck"

"static-promotion" seems to be about "previously, const REF: &T = &expr; was (accidentally) accepted even when expr may contain interior mutability. Now this requires that the type of expr satisfies T: core::marker::Freeze" so should perhaps be changed to "const-promotion" (with or without dash), so that gives the first option of ConstPromote.

Then there is the conversion from &T to &[u8; core::mem::size_of::<T>()]. Specifically in the presence of another &T and where T contains an UnsafeCell (not merely points to one), because then the other ref could be used to change the bit pattern of the memory of T, which I believe would be immediate UB in the presence of a converted &[u8; core::mem::size_of::<T>()], because that shared ref implies constancy of the memory of T which would be violated by doing inner mutation. So that gives variations on TransmuteRefToBytesRef.

Then I wondered what the purpose is of this ref transmute. Is it for enabling some optimization? That would give OptimizeX. Bytemuck seems to use Zeroable, NoUninit, AnyBitPattern among other traits, while ZeroCopy has KnownLayout, Immutable, Unaligned, and IntoBytes. Actually it seems not Immutable (as claimed by the RFC) but this IntoBytes is what is used for this transmuting meaning of Freeze: "Any IntoBytes type can be converted to a slice of initialized bytes of the same size. This is useful for efficiently serializing structured data as raw bytes." Why does the RFC (on a very cursory viewing) seem to suggest that Immutable and IntoBytes are the same? Or perhaps, why does zerocopy separate these traits?

Options:

• ConstPromote
• variations on transmuting references to T to references to bits:
  • TransmuteRefToBytesRef
  • ConvertRefToMemRef
  • ViewRefAsBitsRef
  • ViewRefAsRefToBits
  • ViewBorrowAsBorrowedBits
  • ViewBorrowAsRawMemoryBorrow
  • ViewAsShared
  • many other options
• OptimizeX ?