meeting-2015-11-03.md

2015-11-03

Agenda

• PERMANENT ITEMS:

  • review subteam FCPs https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3Afinal-comment-period

• 1.5 release during work week (aturon)

• cargo check (wycats)

• patterns (nmatsakis) https://internals.rust-lang.org/t/how-to-handle-pattern-matching-on-constants/2846/16

• std::time (wycats) https://github.com/rust-lang/rfcs/pull/1288

• ffi complaint

• red flag on aster (wycats)

1.5 release during work week

• Make sure to prep blog post and relnotes before the work week
• Pay close attention to regressions leading up to the work week

Cargo check

• Workflow for checking successful ability to build, without actually trans-ing; want to be able to do this in "watch" mode as well

• How many subcommands do we want for Cargo? Should this be a first-class thing?

• (Some discussion about stabilization, how this interacts with other compiler changes.)

• ACTION ITEM: make a repo that does this via cargo install, to get started. Just skip the trans step on the final crate.

Patterns

Recapped https://internals.rust-lang.org/t/how-to-handle-pattern-matching-on-constants/2846/16

• ACTION ITEM: measure the results on crater, see how much breakage it would cause to revoke these patterns

std::time

• The time RFC is up for FCP this week (closing tomorrow)

• Source of contention currently is: whether it's OK to have an API that does not offer some guarantees about some aspect of its behavior

• e.g., the way the RFC is written, there are two kinds of guarantees:

  • Monotonicity (if you ask for a time later, you get a bigger time)
  • No guarantees (if you ask for a time later, you might get a smaller time, due to NTP etc)

• Main counterargument: there are other questions you might want to answer. Is the system time UTC or TAI? Is it steady or just monotonic?

• These additional guarantees are not portable

  • So either provide their intersection, or provide a zoo of types

• But you could add guarantees in a later version if it becomes more clear how to do so

ffi complaint

• Saw some commentary along the lines that we haven't put enough effort into FFI improvements (particularly calling C from Rust) -- things like alignment specification, untagged enums, etc. We postponed several RFCs along these lines in the past.
• We're doing pretty well keeping the bigger features on the radar, but it's easy to forget about small papercut fixes
• Going to signal that we would welcome new design/RFC work in these areas, and perhaps look at other areas of postponement for similar treatment