Stream: t-lang/wg-unsafe-code-guidelines

Topic: Freeze


centril (Aug 14 2019 at 13:53, on Zulip):

(I think we should consider exposing Freeze)

@centril what problem would that solve that can't be solved with UnsafeCell<T> ?

See https://github.com/rust-lang/rust/issues/60715

gnzlbg (Aug 14 2019 at 13:59, on Zulip):

that makes sense

gnzlbg (Aug 14 2019 at 13:59, on Zulip):

I thought somebody wanted to expose it in such a way that it can be implemented for their own types

centril (Aug 14 2019 at 14:02, on Zulip):

@gnzlbg I guess that could make sense if you have some type that is !Freeze that you've wrapped inside another type which you want to be Freeze but you've ensured that no interior mutation is possible through the wrapper type

centril (Aug 14 2019 at 14:02, on Zulip):

idk how useful that is

centril (Aug 14 2019 at 14:02, on Zulip):

Freeze can also be used to create an owned type which does not allow mutation at all

centril (Aug 14 2019 at 14:03, on Zulip):

no matter if moved to a new binding or not

gnzlbg (Aug 14 2019 at 14:06, on Zulip):

I'm having a hard time imagine which problems these would solve

centril (Aug 14 2019 at 14:07, on Zulip):

well the latter is useful as a sort of "let's really restrict mutation for code maintainability purposes";
the former swym usecase is more compelling tho

gnzlbg (Aug 14 2019 at 14:08, on Zulip):

the swym usecase of using T: Freeze as bound feels ok

centril (Aug 14 2019 at 14:09, on Zulip):

the case for implementing Freeze manually is probably not compelling, but just wait for someone to do something weird :P

gnzlbg (Aug 14 2019 at 14:10, on Zulip):

but using T: !Freeze as bound doesn't feel that useful,
implementing Freeze for types that would be !Freeze feels like maaybe,

gnzlbg (Aug 14 2019 at 14:10, on Zulip):

implementing !Freeze for types that would be Freeze feels wrong

gnzlbg (Aug 14 2019 at 14:12, on Zulip):
struct Foo(u32);
impl !Freeze for Foo {}  // Foo === UnsafeCell<Foo> ?
impl Foo { unsafe fn next(&self) -> u32 { unsafe { self.0 += 1 }; self.0 } }
centril (Aug 14 2019 at 14:24, on Zulip):

@gnzlbg the usecase for implementing !Freeze manually is mostly to avoid committing (in the semver sense) to being Freeze; you can use PhantomData<Cell<()>> for that tho.

As for negative bounds that isn't a thing...?

gnzlbg (Aug 14 2019 at 14:28, on Zulip):

I thought you can have a generic impl for T, and then specialize it for T: Freeze

gnzlbg (Aug 14 2019 at 14:29, on Zulip):

and now you have separated !Freeze from Freeze

centril (Aug 14 2019 at 14:43, on Zulip):

@gnzlbg maybe something like https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=94a031ddac7b2c5185292531f3f58f46 but rustc refuses to make that work

centril (Aug 14 2019 at 14:44, on Zulip):

but why would you use T: !Freeze as a bound... I could see using T: Freeze as a bound for optimization purposes or for correctness

gnzlbg (Aug 14 2019 at 14:55, on Zulip):

same question, i don't think doing that would be useful

centril (Aug 14 2019 at 14:59, on Zulip):

@gnzlbg it's clearly useful in the swym case...?

gnzlbg (Aug 14 2019 at 15:00, on Zulip):

They use T: Freezw, not T: !Freeze, right? Otherwise I completely misunderstood what they were doing

gnzlbg (Aug 14 2019 at 15:00, on Zulip):

I thought they wanted to use T: Freeze to avoid using types containing UnsafeCell

centril (Aug 14 2019 at 15:00, on Zulip):

@gnzlbg I think we are talking past each other; we both agree that bounding on !Freeze is not useful

gnzlbg (Aug 14 2019 at 15:00, on Zulip):

yep

gnzlbg (Aug 14 2019 at 15:00, on Zulip):

bounding on T: Freeze seems definetely useful

centril (Aug 14 2019 at 15:00, on Zulip):

yep

gnzlbg (Aug 14 2019 at 15:01, on Zulip):

implementing Freeze or !Freeze might be useful

gnzlbg (Aug 14 2019 at 15:01, on Zulip):

i would be fine with allowing people to play with that behind a different feature gate

centril (Aug 14 2019 at 15:01, on Zulip):

I wonder if there are any interesting optimizations you can do through specialization with T: Freeze

centril (Aug 14 2019 at 15:01, on Zulip):

Yep; we should also audit the compiler's use of the lang item

Last update: Nov 20 2019 at 12:50UTC