Hi from 2023! The article is cool, and it's really fun to read! Many thanks!
It seems the content is still relevant so far, so if you don't mind I would like to put a remark(*) and ask a question(?).
(*) In the code block when Bear says
...so it's probably not a good pattern. We could probably come up with a safer API, like that:
'&mut' seems to be redundant - reader is not event mutable:
match&mutreader {
/* arms */
}
(?) Why do we keep unsafe pin calling to create pinned reader within an arm (same code block, a few lines lower):
let reader = unsafe { Pin::new_unchecked(reader) }; // <-- ?
As far as we restricted Self to have reader (field) implementing Unpin trait, we could use safe version of Pin 'constructor' within this implementation -
fasterthanlime
commented
7 months ago
It happened on this page
https://github.com/fasterthanlime/feedback/issues
Here's what the issue is
From
novartoleon reddit: https://www.reddit.com/r/fasterthanlime/comments/mer94f/comment/k6im4io/?utm_source=reddit&utm_medium=web2x&context=3Hi from 2023! The article is cool, and it's really fun to read! Many thanks!
It seems the content is still relevant so far, so if you don't mind I would like to put a remark(*) and ask a question(?).
(*) In the code block when Bear says
'&mut' seems to be redundant - reader is not event mutable:
match&mutreader {/* arms */}(?) Why do we keep unsafe pin calling to create pinned reader within an arm (same code block, a few lines lower):
let reader = unsafe { Pin::new_unchecked(reader) }; // <-- ?As far as we restricted Self to have reader (field) implementing Unpin trait, we could use safe version of Pin 'constructor' within this implementation -
let reader = Pin::new(reader);couldn't we?