Change:
This is a tracking issue for and . Feature gate: #![feature(iosliceadvance)]. Steps: [x] Implement the RFC. [ ] FCP [ ] Stabilization PR. Current API additions: Old issue: Writing I needed to resort to unsafe code to change the underlying slice in (and ). I'm missing a method that can change the underlying slice. said that I should open an issue. Current idea would be something like from the .
Looking for some feedback as to whether this would be accepted.
Can someone reopen this as the tracking issue for ? I've updated the the first comment, but I'm not sure it's 100% correct.
I was trying to in the bytes crate, and noticed there's currently an issue with lifetimes: To allow such a thing externally, we could add a method to that gives the slice with the same lifetime as (whereas uses an anonymous lifetime).
can get around the lifetime issues by replacing self with an empty slice and then replacing it again with the advanced slice? Something like can be found here:
I don't think so. It's not possible to get the inner slice with the same lifetime due to :
it's not an amazing API to build that on top of, but it is possible ():
Oh right, that is using the unstable function. I was referring to be able to implement this now.
Ah, I just assumed since that's what the tracking issue is about. It seems like having along with and would make sense since it's just a newtyped slice (hopefully that's possible with the actual os-specific implementations).
I've been trying to write a function that continuously calls , but it seems like this is not really possible to do without some way of advancing the s (or resorting to , of course). It does not seem to me like vectored IO is very practical without this feature or something equivalent.
Are there any news on landing this? I'm trying to do vectored IO too, and it would be very nice if it were possible to just use this function — I think this is the only unstable feature I currently depend on, and it would be very nice to be able to compile on stable without having to add unsafe code. as discussed above is another primitive that would make it possible to implement as a user, and it would most likely be great to have it, but seeing the way vectored IO is done I can't see a world where a function like isn't required.
The signature of the unstable function in std right now is: It might be a bit confusing that it both modifies (somtimes at least), but also returns the new slice. A would be good. An alternative could be
I agree, I think previous versions didn't return a value. But I can't remember why it returns a value now. If other people agree I could send a pr.
Does the removal of the I-nominated label mean that libs team discussed it and concluded that the signature should change for the alternative you wrote out in your post? (Just coming back here as AFAIK this feature is now the only one blocking me from building on rustc stable, through futures-utils' write-all-vectored feature. I can try to see whether I can PR into futures-utils so that the feature can be implemented without this function, but if there's a known way towards stabilization there's little point in spending that many cycles for it, especially as it'll probably mean having to do unsafe to increase lifetimes)
- I removed the label because there didn't seem to be anything to discuss in a meeting. But if you think there's anything that needs a decision from the libs team I can put it back. (If you have an opinion on the signature of this function, I'd love to hear it in a comment here. :) )
I must say I don't really have any strong opinions on the signature of this function, but thank you for asking! Both ways sound reasonable enough to me, as it's expected to be a low-level building block; though I must say that the alternative you suggested does “feel” slightly better to me (but I don't know whether this feeling is worth anything, especially as since futures-rs got its feature I no longer even call this function myself). FWIW, digging into github makes it look like the API changed from to here (), I'm not totally sure why either, maybe there was off-band discussion. Overall, my comment was mostly to figure out the current state of stabilization and what it's blocked on; I guess it means it's currently blocked on refining the signature, and then following the usual process of waiting for some time for the ecosystem to settle, and if things look all good stabilizing — though I'm not sure by which process “refining the signature” should be happening, but it's the first time I really look at the stabilization process (as it's the first time I both depend on a single nightly feature and actually care about building on stable, I guess), so I suppose it will eventually happen following the normal procedure :) Anyway, thank you for your feedback!
I agree with I don't really care about the signature either, I'm ok with both. The version is uncommon in Rust, but I think the is a little more awkward to use at times. For example from futures calls before each call to (). Either way I think we should pick a version, accept it's not perfect, and stabilise it.
To reduce confusion, could you please edit the first post of this tracking issue to give the current signatures of and , rather than referencing an old proposal that doesn't match the current API?
Done.
We could sidestep the signature issue by just implementing a method on the itself like . That would at least make it possible for the user to create a method with either signature. Basically giving the user the need-to-have without the nice-to-have. Having a method for advancing on the also seems like it would be a good addition in isolation.
I implemented that on the underlying sys types, e.g:
Oh nice. I now see the "old issue" in the issue is actually what I described. I think exposing this would be a nice MVP. Biggest problem is that it collides with the existing name. I guess the existing one could be renamed to something like . Thoughts?
I was thinking about this some more and I think having the possibility to advance both a single and a slice of s is quite useful, I've needed both a couple of times myself. So, I want propose a slight change in design to make both possible:
I've created a pr for the changes in
I was wondering what the status of this features is? I could really use this API in something I'm working on.
I've being using it without issues, so from my point of view this is ready for a FCP as the last activity was back in June ().
Please FCP this. It is quite annoying implementing functions that do vectored I/O without any straightforward way to advance.
Right now, panics if its argument is larger than the amount of bytes in the slice(s), but does not. Both should probably have the same behaviour, and it should be documented. Other than that, this seems ready for stabilization.
I think both of them should panic in that case, but am open to hear why the non-panicking behaviour would make more sense.
PR for that:
I think the panic behavior is reasonable since these functions are analogous to . On the other hand, there is also unstable which returns a instead. However, for an iterator it may not be possible to know the total number of items whereas for the user may always check .
Are there any concerns with the current panic behavior? If not, can this be FCPed?
Really looking forward for this being stabilized. This is quite useful in network programming.
I do have one quick question prior to it stabilizing: do you want to require people to do /, or should both methods return booleans, returning if the buffer is non-empty and otherwise? The latter would be make calling code a little easier to follow IMHO, since you can just use it as the condition in most loops: The code itself , and it's pretty trivial for the inner buffer.
How can progress be made on this issue? It is unclear to me what concerns are blocking this.
it hasn't seen any changes for a year and half (?), so I think someone just needs to create a stabilisation pr.
I think a FCP is needed first.
Isn't that usually done in the stabilization pr?
I'm not sure, but I have usually seen FCPs in tracking issues.
+1 for starting FCP, this is a really useful feature
This is a generally useful API for working with vectored I/O. fcp merge I think making / return a bool would be confusing, it isn't immediately clear from the function name what the return value means. Code is much clearer if it explicitly queries on the slice instead.
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
The method is an inherent method on a type that implements for . Don't we usually try to avoid adding new inherent methods in that case? (I suppose this would only become an issue if we a method named to . Seems unlikely but not completely impossible?)
FWIW, bytes provides advance on &[u8] via Is there a reason not to put advance directly on &[u8] here? I think that would be slightly incompatible to move later...
Arguably it's inconsistent, since the other method takes a slice of s. However, I could see some benefit of moving both to methods via a pair of extension traits (say, and ): You could provide overloads for both / and /, all using the same name. These traits could also include and methods, and those could be used to be polymorphic over normal and vectorized reads, easing migration between the two a lot.
That's because the method works on a slice of (hence the name), thus needs mutable access to , which means , which doesn't work with a variant of . That said, I'm perfectly fine with changing to to avoid this issue mentioned by
I think we may use to compute . Because the contents of may alias, it is theoretically possible that the total lengths of the s exceed , causing an overflow on .
I opened to handle that.
Although it is also still unstable, a related set of functions on uses a different naming pattern: Applying the same here would read kind of odd though because of the repetition of : Perhaps we could name them and ?
I fail to see the relation between the two functions. does a (type) conversion, while manipulates the slices, I don't think they should follow the same naming pattern. Can you elaborate why you think they should?
is the "action" of the function and equivalent of "advance" for . It is prefixed by because the first argument isn't but a slice of . Following that logic, the functions should be: Perhaps it should be a free-function instead and we offer only ?
It is also worth noting that and only give you a . How are implementations meant to advance these anyway?
I still fail to see the relation, but those names seem fine with me as well. At this point I don't really care about the names to be honest. See , shouldn't advance the buffers.
What is the status of this feature? There are no concerns in the FCP.
Hi, is there any progress of this feature?
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
The following assert won't work after this if the call IoSliceMut::advance() in it's .
in your example you don't call , so I don't see how it's relevant to the method?
Yes I didn't call but the may call that indirectly? What I want to say is that, there is no guranteen that won't get called inside or any other existed functions that take a param as a way to receive data.
I don't think we can guarantee that the method will never be incorrectly used. Same for for example... I don't know what you expect the standard library to change about this.
Before the stabilization of iosliceadvance, users can use both the original buffer and also the to get the read data. After the stabilization, I'm confused with which one should be used? For all old methods that take a , should I still read the data by using the old way? Will it broken without noticeable API changes?
Consider filing a bug report against anyone who sets them incorrectly. It's not Rust's fault if someone implements wrong. It's the fault of whoever wrote the bad implementation for that trait instance method.
The should be documented to specify what's the wrong implementation. So I opened for further confirmation.

Discussion:
/// # Examples /// /// ``` <del> /// #![feature(io_slice_advance)] /// </del> /// use std::io::IoSliceMut; /// use std::ops::Deref; ///

/// assert_eq!(bufs[0].deref(), [2; 14].as_ref()); /// assert_eq!(bufs[1].deref(), [3; 8].as_ref()); /// ``` <del> #[unstable(feature = "io_slice_advance", issue = "62726")] </del> <ins> #[stable(feature = "io_slice_advance", since = "CURRENT_RUSTC_VERSION")] </ins> #[inline] pub fn advance_slices(bufs: &mut &mut [IoSliceMut<'a>], n: usize) { // Number of buffers to remove.

/// buf.advance(3); /// assert_eq!(buf.deref(), [1; 5].as_ref()); /// ``` <del> #[unstable(feature = "io_slice_advance", issue = "62726")] </del> <ins> #[stable(feature = "io_slice_advance", since = "CURRENT_RUSTC_VERSION")] </ins> #[inline] pub fn advance(&mut self, n: usize) { self.0.advance(n)

/// # Examples /// /// ``` <del> /// #![feature(io_slice_advance)] /// </del> /// use std::io::IoSlice; /// use std::ops::Deref; ///

/// IoSlice::advance_slices(&mut bufs, 10); /// assert_eq!(bufs[0].deref(), [2; 14].as_ref()); /// assert_eq!(bufs[1].deref(), [3; 8].as_ref()); <del> #[unstable(feature = "io_slice_advance", issue = "62726")] </del> <ins> #[stable(feature = "io_slice_advance", since = "CURRENT_RUSTC_VERSION")] </ins> #[inline] pub fn advance_slices(bufs: &mut &mut [IoSlice<'a>], n: usize) { // Number of buffers to remove.