lkml.org 
[lkml]   [2021]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH 00/13] [RFC] Rust support
Date
From: Linus Walleij
> Sent: 22 April 2021 11:03
...
> I go to patch 12/13 and I see things like this:
>
> +/// A descriptor of wrapped list elements.
> +pub trait GetLinksWrapped: GetLinks {
> + /// Specifies which wrapper (e.g., `Box` and `Arc`) wraps the list entries.
> + type Wrapped: Wrapper<Self::EntryType>;
> +}
> +
> +impl<T: ?Sized> GetLinksWrapped for Box<T>
> +where
> + Box<T>: GetLinks,
> +{
> + type Wrapped = Box<<Box<T> as GetLinks>::EntryType>;
> +}
> +
> +impl<T: GetLinks + ?Sized> GetLinks for Box<T> {
> + type EntryType = T::EntryType;
> + fn get_links(data: &Self::EntryType) -> &Links<Self::EntryType> {
> + <T as GetLinks>::get_links(data)
> + }
> +}
>
> My God. Lose the horrible CamelCase to begin with. I hope the
> language spec does not mandate that because our kernel C style
> does not use it.

That:

1) Looks as though it could be generated by token pasting in a #define.
2) Seems to be full of what look like casts.

I really wouldn't want to bump into multiple copies of it.

The other issue is that (all most) all uses of a symbol
can be found by running:
grep -r --include '*.[chsS]' '\<symbol\>' .
often used as:
vi `grep -l -r '\<symbol\>' .`

But it looks like the rust wrappers are going to break that.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
\
 
 \ /
  Last update: 2021-04-22 16:10    [W:0.251 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site