Re: [PATCH v2] rust: pin-init: add `#[bind]` attribute to access previously initialized fields

[Danilo Krummrich <dakr@kernel.org>]

On 9/10/25 4:59 PM, Benno Lossin wrote:
> On Wed Sep 10, 2025 at 4:02 PM CEST, Boqun Feng wrote:
>> On Wed, Sep 10, 2025 at 02:19:00PM +0200, Benno Lossin wrote:
>>> On Wed Sep 10, 2025 at 12:40 PM CEST, Alice Ryhl wrote:
>>>> On Wed, Sep 10, 2025 at 12:36 PM Benno Lossin <lossin@kernel.org> wrote:
>>>>>
>>>>> On Wed Sep 10, 2025 at 12:17 PM CEST, Alice Ryhl wrote:
>>>>>> On Wed, Sep 10, 2025 at 12:07:53PM +0200, Benno Lossin wrote:
>>>>>>> Assigning a field a value in an initializer macro can be marked with the
>>>>>>> `#[bind]` attribute. Doing so creates a `let` binding with the same
>>>>>>> name. This `let` binding has the type `Pin<&mut T>` if the field is
>>>>>>> structurally pinned or `&mut T` otherwise (where `T` is the type of the
>>>>>>> field).
>>>>>>>
>>>>>>> Signed-off-by: Benno Lossin <lossin@kernel.org>
>>>>>>
>>>>>> Is there a reason we can't apply this to all fields and avoid the
>>>>>> attribute?
>>>>>
>>>>> Adding the attribute was due to Boqun's concern on v1 [1]. I think it
>>>>> might be surprising too, but I'm also happy with no attribute.
>>>>>
>>>>> [1]: https://lore.kernel.org/all/aLshd0_C-1rh3FAg@tardis-2.local
>>>>
>>>> IMO the ideal is if it works without an attribute. Perhaps trying that
>>>> in the kernel is a reasonable experiment to find out whether that's
>>>> reasonable to do for the general language feature?
>>>
>>> @Boqun what is your opinion on this?
>>>
>>
>> If we plan to make the in-place initializer language feature behave
>> similar, as I asked here [1], then dropping `#[bind]` seems good to me.
> 
> I don't think we can promise how that language feature is going to look
> like. It will definitely support accessing already initialized fields,
> but in what form remains to be seen.

And as Alice said, getting some experience from real applications is not the
worst thing. We can always change it if we see it causing too much pain.