A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://github.com/rust-lang/libs-team/issues/627 below:

GitHub ยท Where software is built

Proposal Problem statement

MaybeUninit<T> is required for references in order to maintain soundness, but no such restrictions exist for pointers, and *const MaybeUninit<T> is mostly just an unnecessary layer of abstraction. The goal is to make it easier to convert *const MaybeUninit<T> to *const T, especially due to the fact that <[MaybeUninit<T>]>::as_ptr returns it.

Motivating examples or use cases

Right now, the MaybeUninit::slice_as_ptr and MaybeUninit::slice_as_mut_ptr methods exist to do a direct conversion from &[MaybeUninit<T>] to *const T and &mut [MaybeUninit<T>] to *mut T, but these methods are clunky and it's not clear how to fix this.

As stated, since pointers don't have the same initialization requirements as methods, it can be very desirable to use pointer-based write methods instead of those for slices, especially due to the lack of initialization requirements. However, these methods will require the "initialized" pointers, not the MaybeUninit<T> ones, and it's nice to be able to have an easy way to perform this cast without requiring additional type ascriptions (cast::<T>()).

Additionally, this way of doing MaybeUninit<T> -> T pointer conversion is more flexible than an inherent slice-based method such as <[MaybeUninit<T>]>::as_init_ptr, and would avoid the potential variability between calling such an as_init_ptr method and as_ptr().cast_init().

Solution sketch

Essentially, add the following methods:

impl<T> *const MaybeUninit<T> {
    pub const fn cast_init(self) -> *const T { self.cast() }
}
impl<T> *mut MaybeUninit<T> {
    pub const fn cast_init(self) -> *mut T { self.cast() }
}
Alternatives

There are currently three alternates:

  1. Keep the MaybeUninit::slice_as_ptr and MaybeUninit::slice_as_mut_ptr methods, don't add these. This option is undesirable because this method requires the explicit function call syntax as well as importing MaybeUninit in code that may not otherwise need to do so.
  2. Replace the explicit functions with real methods on [MaybeUninit<T>] slices. This is still not preferred due to the fact that cast_init can work on pointers obtained in other ways too.
  3. Remove all these methods and don't add a replacement. This isn't great because cast::<T>() will require type ascriptions, but cast::<T>() isn't necessarily any worse than cast_init(), just a little less clear.
Links and related work What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

Second, if there's a concrete solution:


RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4