I'm working up a big PR for goblin that addresses this and the earlier Size/Units change, which seems like a representative way to evaluate the impact. (Also, I broke it/I bought it?)

I opened PRs in both goblin and faerie. Good thing too; I had missed updating the IOwrite trait.

If we say:

    /// Write `n` of type `T` at offset `I` with context `Ctx`
    /// # Example
    /// ```
    /// use scroll::{Pwrite, Pread, LE};
    /// let mut bytes: [u8; 8] = [0, 0, 0, 0, 0, 0, 0, 0];
    /// bytes.pwrite_with(0xbeefbeef, 0, LE).unwrap();
    /// assert_eq!(bytes.pread_with::<u32>(0, LE).unwrap(), 0xbeefbeef);
    fn pwrite_with<T,V>(&mut self, n: V, offset: usize, ctx: Ctx) -> result::Result<usize, E>
        where T: TryIntoCtx<Ctx, <Self as Index<RangeFrom<usize>>>::Output, Error = E> + ?Sized,
              V: Borrow<T>,
    {
        let len = self.measure_with(&ctx);
        if offset >= len {
            return Err(error::Error::BadOffset(offset).into())
        }
        let dst = &mut self[offset..];
        n.borrow().try_into_ctx(dst, ctx)
    }

These work:

• bytes.pwrite_with(0xbeefbeef, 0, LE)
• bytes.pwrite_with(&0xbeefbeef, 0, LE)

This does not work, because now there's two type parameters:

• bytes.pwrite_with::<u32>(0xbeefbeef, 0, LE)

These also work:

• bytes.pwrite_with::<u32,_>(0xbeefbeef, 0, LE)
• bytes.pwrite_with::<_,u32>(0xbeefbeef, 0, LE)
• bytes.pwrite_with::<u32,u32>(0xbeefbeef, 0, LE)

Using Borrow makes sense to me. Does pwrite_with::<...> get used much in practice? I guess it's only for constants, and for those I think bytes.pwrite_with(0xbeefbeef_u32, 0, LE) is clearer.

I'm pretty excited about this version @willglynn ! I checked out your branch this weekend and played around with it, if nothing else comes up, I think this might be the way forward :)

So we can now do stuff like this:

#[test]
fn pwrite_big_struct() {
    use scroll::{LE, Pwrite};
    #[derive(Pread, Pwrite, Copy, Clone)]
    struct Big {
        arr: [u8; 100000000],
    }
    let big: Box<Big> = box (unsafe { ::std::mem::uninitialized() });//Big { arr: [0; 100000000] };
    let mut bytes = vec![0; 100000001];
    //let big = box bytes.pread_with::<Big>(0, LE).unwrap();
    let _ = bytes.pwrite_with(&* big, 0, LE).unwrap();
    assert!(false);
}

which was my original pain point when trying to write a large struct which was boxed :D (Preading is still an issue, and boxing doesn't fix it atm, but I think we could in principle fix that too, at another time)

Just grepping through a couple of codebases, I believe @philipc is correct (as usual) and afaics only goblin atm uses pwrite::<T> and this is because it relies on eliding an into() call, which is easily fixed (and probably better with an explicit into anyway):

src/mach/symbols.rs
277:                (bytes.pwrite_with::<Nlist32>(self.into(), 0, le)?)
280:                (bytes.pwrite_with::<Nlist64>(self.into(), 0, le)?)

src/mach/segment.rs
201:            bytes.pwrite_with::<Section64>(self.into(), 0, ctx.le)?;
203:            bytes.pwrite_with::<Section32>(self.into(), 0, ctx.le)?;
374:            bytes.pwrite_with::<SegmentCommand64>(self.into(), 0, ctx.le)?;
376:            bytes.pwrite_with::<SegmentCommand32>(self.into(), 0, ctx.le)?;

So yea, overall really like this direction, seems like with a minor sacrifice we can keep the owned usage for literals (and other Copyables?). If we do end up going this route, I think we'll need some explicit documentation about why passing a type parameter via turbofish is banned/problematic, etc.

Anyway, great work !

Cool! I plan to:

• Keep the [Try]IntoCtx traits taking &self,
• Keep the scroll_derive changes around &self,
• Change the Pwrite and IOwrite traits to use Borrow as described above,
• Reset everything that's not in the list above,
• Fix everything that's broken

I'll comment when that's done and I've force-pushed the results.

Friendly ping @willglynn . Would definitely like to see this get pushed through? Do you have a branch WIP anywhere, or need to offload some work to someone else? Hoping we didn't lose steam on it as i think its definitely something that's needed :)

@m4b 👍 I've been traveling and haven't looped back to this. My most current work is still in this branch, and it needs to be re-worked per the plan above. I expect to have more time right at year's end.

No worries, thanks for the update! :)

@willglynn gentle ping :) is there any chance of continuing here, or should we explore other options? If you're busy don't worry at all, or don't want to work on it anymore, don't feel bad at all/responsible whatever, just trying to get a feel for how to proceed/what to do.
If you get a chance let me know; maybe someone else can pick it up or I can take a look at it, etc.
As I understood it its basically working, modulo using borrow to deal with the ergonomic issue of pwriting constants?

Sorry! I've been traveling some more and haven't got back to this. Probably the right thing to do is to reset to master to integrate the latest changes, change the interfaces as described upthread, and then just chase the build errors until they're gone again. This is still a thing I'm interested in doing, but if someone else beats me to it, that'd be cool too 👍

gosh i don't even know where to begin to move this as a PR into the scroll repo :(

oops i thought this PR was in old scroll_derive repo, ok never mind :)

I cargo fmt scroll and scroll derive; was hoping something like this would get resolved, but doesn't seem like it's going to happen, and now that fmt has happened there will be conflicts everywhere. going to close this; we can revisit again, or possibly never :)