Re: [PATCH 1/6] rust: alloc: add Vec::push_init

["Eliot Courtney" <ecourtney@nvidia.com>]

On Wed Aug 19, 2026 at 8:23 PM JST, Danilo Krummrich wrote:
> On Mon Aug 17, 2026 at 2:56 PM CEST, Eliot Courtney wrote:
>> +    pub fn push_init<E>(&mut self, init: impl Init<T, E>, flags: Flags) -> Result<(), E>
>> +    where
>> +        E: From<AllocError>,
>
> This signature rejects impl Init<T, Infallible>, which is the reason why we have
> e.g. Box::init() and Box::try_init() with different fallible signatures.
>
> So, if we follow InPlaceInit, it'd be
>
> 	pub fn push_init<E>(&mut self, init: impl Init<T, E>, flags: Flags) -> Result<(), Error>
> 	where
> 	    Error: From<E>;
>
> and
>
> 	pub fn try_push_init<E>(&mut self, init: impl Init<T, E>, flags: Flags) -> Result<(), E>
> 	where
> 	    E: From<AllocError>;
>
> In theory we could also simplify it to
>
> 	pub fn push_init(&mut self, init: impl Init<T>, flags: Flags) -> Result<(), AllocError>
>
> and
>
> 	pub fn try_push_init<E>(&mut self, init: impl Init<T, E>, flags: Flags) -> Result<(), E>
> 	where
> 	    E: From<AllocError>,
>
> However, InPlaceInit actually achieves more with the init() and try_init()
> distinction:
>
>   What init() accepts, but try_init() does not accept:
>     - impl Init<T, Infallible>
>     - impl Init<T, E> where Error: From<E> but NOT E: From<AllocError>
>
>   What try_init() accepts, but init() does not accept:
>     - impl Init<T, E> where E: From<AllocError> but NOT Error: From<E>
>
> So, with the simplification we'd technically lose out on the
>
> 	impl Init<T, E> where Error: From<E> but NOT E: From<AllocError>
>
> case.
>
> In any case, init() and try_init() seem a bit mixed up on their purpose
> regarding fallibility and error type strategy, but in order to really cover all
> cases I think it is necessary.

Wow this is quite confusing hey. `push_init` meaning unify all the
errors to Error ("we don't care so much about the exact error type"),
`try_push_init` meaning unify all the errors to Init's E ("we care about
the error from our Init")?

We haven't considered the case where we actually care about both errors,
in which case we'd want to define an enum. Like PushInitError<I, E>
{AllocError(I), InitError(E)}. We can conditionally impl the conversion
to Error. Then we only need push_init(I: Init<T, E>)->PushInitError<I,
E>.

Compared to Gary's unify! proposal which chooses one unified type per
unordered pair (extensible to N types, but the operation isn't
guaranteed to be associative so needs some care) of types, this means we
need to define the error type manually. But it also means callers can do
different things based on the underlying error types and also get the
initializer back if they want.

On a more general note has there been any discussion on error handling
in general? It looks like we often just use Error and collapse things to
errno values. In userspace, per call errors are kinda solved, by e.g.
`thiserror` and `anyhow`. The distinction here feels a bit similar to me
- let callers of kernel APIs (like Vec) get a sum type error
(thiserror-like) and let them decide what to do which is usually
collapse to Error (anyhow-like).

I think it's worth changing push() to take an Init<T> as well. That's a
third signature push(Init<T>)->AllocError? that isn't representable
using push_init(Init<T,E>)->Error? or try_push_init(Init<T,E>)->E?. I
think we'd then just have try_push(I: Init<T, E>)->PushInitError<I, E>
then (ArrayVec can also have this push / try_push pair). I feel this
distinction is a bit easier to understand than push, push_init,
try_push_init.

So concretely, what about just:
- push(&mut self, init: impl Init<T>, flags: Flags) ->
    Result<(), AllocError>
- try_push<I: Init<T, E>, E>(&mut self, init: I, flags: Flags) ->
    Result<(), PushInitError<I, E>>