Champion Meeting Notes, 2024-03-04

[tabatkins]

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

• when prefix - Tab hasn't completed their action to document other langs

• non-boolean extractor - switch to preferring Array-like, and only falling back to iterator.

  • Do this for array patterns too? Similar perf arguments apply...
  • talk about C# and other plenary details

• Jordan says all objects are technically array-like, since .length check coerces

  • Tab says this is novel, probably we should be checking for the existence of a 'length' property
  • Jordan prefers that, but it's novel.
  • Ron gave examples in proposal of an iterator that wasn't an array
  • Ron: right now iterators are slow because engines don't opt, there's low-hanging fruit here, but no knowledge of plans to fix
  • so proposal: novel "strict array-like" that checks the existence of a length property, requires the value to be an integer
  • Jack: can we just use the AO?
  • Jordan: That coerces. We could do the strict checks first then call the AO
  • Ron: Or just modify the AO to have a strict flag
  • Question of own vs inherited, group is unsure
  • Ron: function.length would qualify it as an array-like, should we filter that out?
  • Tab: don't think the lang generally cares if you mess up in that way (forgetting to call your function object)

• Ron: c#'s deconstruct uses ref/out params, have a pending proposal but it's probably too far off to matter

• Ron: Python didn't do custom extractor, they did instanceof and a list of props to access

  • Jack: Not a fan of it, it looks too limited
  • Ron: PEP says they couldn't find reasonable use-cases that weren't reasonably addressed by the simpler version, but I do prefer our custom matcher

• Group okay with strict array-like, falling back to iterator

  • Jordan: if strict array-like is too weird, then just using literal Array
  • Jack: Array can still invoke user-code tho
  • Jordan: not the isArray check, just the index accessing, which is fine
  • Ron: remember we want to extend this to tuples eventually (group agrees)
  • Ron: should push on impls too to generally opt array destructuring
  • Jordan: If React isn't already an argument for that opt, unsure we'll be a significant additional push
  • Jack: maybe we can commit the opt ourselves and then just rely on it :)

• Tab: do we want to apply the strict array-like to array patterns too?

  • Ron: wary of making it too different from destructuring
  • Jordan: agree, we can do weird new stuff for our new extractor thing, but should stay closer to destructuring

• Jack: specifically, do champions prefer Array or strict array-like?

  • Ron: for typechecking, prefer Array (it rules out accidental Function)
  • general agreement
  • Jordan: and if that fails, our fallback proposal is just an Array, no fallback

• Tab: are we aiming for next meeting?

  • Jordan: yes, let's aim for it. we can slip if we have to, but should try for Stage 2 if possible at upcoming one
  • Ron: if we're ready early, should get Daniel Ehrenburg in, he gave good extractor feedback
  • Jordan: Shu too.
  • Daniel: good to get it front of us Moz early too
  • Jordan: yeah, best to show up to plenary with no objections, let's do it
  • Tab: I'll commit to getting the readme PR up-to-date this week
  • Jack: and spec PR is up-to-date too

[mAAdhaTTah]

Jack: can we just use the AO?

What's the "AO"?

[tabatkins]

Abstract Operation (in this case, the one checking to see if something is array-like)