Whether ManuallyDrop can be implemented using the language's own capabilities？

help
1

Whether ManuallyDrop can be implemented using the language's own capabilities？
Why are pointer operations defined in the standard library?

2

ManuallyDrop is lang item, which means it is part of the language itself, and (most likely) you can't implement it with other parts of the language.

Not sure what are you asking. It has to be defined somewhere, right? And to be pedantic, it's in core, not std.

3 Likes
3 
pub macro addr_of_mut($place:expr) {
    &raw mut $place
}

Where is this syntax recorded？

4

There's an attribute #[allow_internal_unstable(raw_ref_op)] on top of this macro, likely referring to this unstable feature.

2 Likes
5

Hope rust doesn't give std a back door!

6

rust, which has no language reference and keeps opening back doors to the standard library, is now just a toy.

7

It absolutely does.

Sorry, what?

???

3 Likes
8

This is absolutely the wrong way to look at things. We could "close" all those doors by hard-coding things in the language rather than having them in the standard library at all, but that would make them substantially less reliable and less auditable than they are now.

14 Likes
9

I think ManuallyDrop would be implementable by using MaybeUninit, except… MaybeUninit uses ManuallyDrop internally!

I think that is only because union doesn't allow Drop types. If Rust let union leak memory, then the union would be the lowest-level magic for both of the wrapper types.

4 Likes
10

It's the front door. The standard library, or rather core, is a core part of the language.

8 Likes
11

Could it be a union-based wrapper around SizeAndAlignOf<T>, with the constructor being a transmute?

EDIT: I just thought of one downside to this, which is that it would surely inhibit niche value optimizations

1 Like
12

Hmm… I believe, we might be fueling the misconception that syntax like this is somehow normal library code using an undocumented part of the Rust language, by how the “Source” button just takes you directly to this code. For a macro like addr_of_mut, which uses both unstable macro syntax, and unstable &raw syntax internally, this experience shows you “source code” without all that clear of an indication that what you’re looking at should for all practical purposes already be considered compiler-internals. This applies for many things like lang-items, functions involving unstable syntax, intrinsics, and the like.

4 Likes
13

FWIW, &raw is stabilized in the 1.82 beta. A meaningful part of the stabilization reason was making it clearer that addr_of! isn't doing any particularly special magic to its place argument.

Then I suppose C++ is just a toy as well, since it's impossible to implement all of <type_traits> using standards compliant code without using std. If you allow for the use of compiler builtins, then the exact same allowance should apply to unstable language functionality in Rust, which serves the exact same purpose. It doesn't matter if it's spelled &raw mut or builtin#addr_of_mut, it's the same thing either way.

Rust actually has one of the most self-hosting standard libraries of any "popular" language. Even C before C11 (_Generic) exposed things in the library that were obviously impossible to write in the surface language (generic math functions).

9 Likes
14

Not fully, because ManuallyDrop preserves validity invariants.