# Libs-API Meeting 2023-01-31

###### tags: `Libs Meetings` `Minutes`

**Meeting Link**: https://meet.jit.si/rust-libs-meeting-crxoz2at8hiccp7b3ixf89qgxfymlbwr
**Attendees**: Amanieu, David, Josh Triplett, Mara, The 8472, Chris Denton

## Agenda

- Triage
- Anything else?

## Triage

### rust.tf/54140 *Tracking Issue: Procedural Macro Diagnostics (RFC 1566)*

No progress yet.

### rust.tf/106541 *implement const iterator using \`rustc\_do\_not\_const\_check\`*

Comment from Thom:

> The #[rustc_do_not_const_check] iterator one (https://rust.tf/106541) seems clearly more maintainable from a libs perspective, but given the history of the issue with libs-api I figured I'd bring it up (also for discussion on whether or not libs-api is okay with having the impl). It seems unlikely to me that this design will stand long-term (but what do I know), but it's unstable, so I'm unsure that matters.
>
> I think it's also worth covering if other (similarly maintainable) impls fall under the "we generally just let wg-const-eval experiment with what they want for unstable const stuff" guideline that we more or less follow.

Seems okay, but what safety mechanisms are in place to prevent accidental stabilization?

Mara left a comment.

### rust.tf/106643 *Allow only implementing \`Read::read\_buf\`*

Discussed last time.

There was some worry about diagnostics.

David to leave a comment.

Tracking issue for the attribute: https://github.com/rust-lang/rust/issues/107460

### rust.tf/107200 *io: soften ‘at most one write attempt’ requirement in io::Write::write*

[discussion on write vs write_all]

Current impl of BufWriter::write does sometimes perform two underlying write() calls. If the buffer already has data, and you do a write larger than the buffer. Is that a bug? [Discussion]

Example: BufWriter with a buffer of 100, and you're doing alternating small and big writes (1, 1000, 1, 1000, etc.). Should that do syscalls of [1, 1000, 1, 1000, ..] or [100, 901, 100, 901, ..]?

The 8472 to look up some previous discussion.

Let's do an FCP.

Josh to comment and start FCP.

### rust.tf/107276 *Windows: Path API Incorrectly Handles Alternate Data Stream Identifiers*

~~Time to just rip out std::path entirely~~ ;_;

Enums like https://doc.rust-lang.org/stable/std/path/enum.Component.html and https://doc.rust-lang.org/stable/std/path/enum.Prefix.html shouldn't have been like that. Hard to fix now. :(

Current situation is weird: from the type system's perspective, it is basically the union of Windows and Unix (see the enums above), but the runtime behavior does depend on the host os.

Time to fix? But how?

Path 2.0?

For std::path::Path, there's not much we can do. Fwiw, Python also doesn't handle data stream paths.

### rust.tf/rfc3362 *Command improvements for ergonomics and error handling*