Champion Meeting Notes, 2023-12-11

[tabatkins]

Attendees: Jack, Jordan, Mark, Ron, Tab, Daniel Minor

(I joined late, so anything that happened previously will have to be edited in by Jordan or someone else.)

do-exprs

Plan is to proceed as if they'll exist, but block stage 3 (whether formally or informally) until we know one way or the other. Confident we can engineer around either outcome.

when prefix

Just discussed it again, didn't come to a conclusion on whether to keep it or leave it out.

• Jordan is primary dissenter, wants to keep it in
• Tab would like to remove it, but is fine if we do keep it.
• Ron would like to remove it.

It would be useful to document other pattern language's decisions in this regard and (if possible to determine) their rationale, regardless of what we choose, so we'll do that. (Tab volunteers to write up an issue.)

There was also some related discussion on boundary tokens around the RHS.

void pattern

Decided that, tho useful, this is a technically unnecessary piece, and reducing syntax as much as possible is important. Champion consensus is to move it back to the "future work" section.

• We can potentially revive it after achieving stage 2, once committee has gotten used to the existing syntax weight. Worst case it's an entirely separate proposal.
• Jack had concerns about a maxmin class proposal problem, but we believe we're not making any compromises that'll make it hard to bring this back later. Seems trivial to add at any point.
• Jordan's big concern is that there are lots of similar places in the language where we'd want the ability to elide a binding, and we can probably get an omnibus proposal going to add void everywhere.
• Ron is swamped with proposals atm, but might be able to drive that later.

true/false vs truthy/falsey

Decided to relax to just requiring truthy/falsey when called in boolean context. Extractor context still requires a strict true/false (or iterator), to allow us to expand our options in the future.

• Jordan wants to ensure that predicates designed for general usage are easily usable here too; we did adapt the syntax to ensure that predicates are usable as patterns.
• Jack has a concern about blocking future extensibility, but Tab argues that the boolean context really has no ability to be extended at all, so it's safe to widen to truthy/falsey.
• Ron is slightly concerned about the inconsistency between the two modes, but agrees that the predicate use-case is important.

plus/minus

Discussed the +x/-x patterns.

• Decided that only a literal +0 or -0 triggers the "signed zero" test; if your variable happens to contain a zero, then +x/-x will just use the normal test which doesn't care about zero sign.

• Decided that the +x/-x patterns are valuable to keep in the proposal.

  • Ron initially wasn't convinced of their value.
  • Tab argued they let us "de-specialize" the +Infinity/-Infinity patterns. (Ron suggested Number.POSITIVE_INFINITY/etc, but group generally agreed they had minimal usage in the wild and weren't a great replacement.)
  • Jack argued that they were useful in many variable cases. Tab concurred, and brought up matching against points or vectors. Ron agreed this was useful.

• Decided that +x/-x would indeed coerce non-Number values.

  • We'll review the recent "stop coercing things" discussions, but we're pretty sure this doesn't run afoul of that - +x is already an explicit "please coerce this to a number" signal in JS code.

[mgaudet]

The new Mozillian was @dminor