@@ -64,18 +64,28 @@ fine: inlining that reference everywhere has the same behavior as computing a
6464new reference each time. In both cases, there exists exactly one instance of
6565the mutable memory that everything references.
6666
67- ### 3. ` Sync `
67+ ### 3. ` Send `
6868
69- Finally, the same constant reference is actually shared across threads. This is
70- very similar to multiple threads having a shared reference to the same ` static ` ,
71- which is why ` static ` must be ` Sync ` . So it seems like we should reject
72- non-` Sync ` types, conforming with the desugaring described above.
69+ Finally, the same constant value is actually shared across threads. This is
70+ very similar to sending the same value across threads, so it seems like we
71+ should reject non-` Send ` types. For shared references, this means the pointee
72+ type ought to be ` Sync ` . That is already required for ` static ` items, so this
73+ is consistent with the desugaring described above.
7374
7475However, this does not currently happen, and there are several crates across the
7576ecosystem that would break if we just started enforcing this now. See
7677[ this issue] ( https://github.com/rust-lang/rust/issues/49206 ) and the
7778[ PR attempting to fix this] ( https://github.com/rust-lang/rust/pull/54424/ ) .
7879
80+ One could make the argument that the value does not have to be ` Send ` because it
81+ is not actually sent to other threads; instead, conceptually, each thread
82+ re-does the same computation. But we know they will all come to the same
83+ result. This works, except when we consider address identity: with references
84+ in the ` const ` , all threads will get the same address, unlike in case of a
85+ per-thread recomputation which would lead to different addresses. As a
86+ consequence, non-` Send ` ` const ` without references are fine, but once references
87+ and thus address identity comes into play, we have a problem.
88+
7989* Dynamic check.* It is unclear how the Miri engine could dynamically check this.
8090
8191### 4. Drop
0 commit comments