Procedural question w.r.t. merged proposals

[mathiasbynens]

This proposal is now effectively a combination of two related-but-separate features, united behind a single flag:

• RegExp set notation (this repository)
• properties of strings (f.k.a. “sequence properties”)

For properties of strings, we already had spec text, that was even already being reviewed by stage 3 reviewers.

Given the overlap w.r.t. spec text changes between the two proposals, how should we proceed?

• Shall we write a single spec patch for both proposals, or somehow try to keep spec patches separate?
  • IMHO, the latter seems trickier to organize, and we’d want the two features to eventually land at the same time in the spec, to ensure implementations don’t ship the new flag while only supporting 1 of the 2 features.
• Should we merge the two proposal repositories?
  • My gut feeling is to keep the repositories separate, as the two features are individually motivated, even if they’re most powerful in combination. We would then continue to separately ask for stage advancement (similar to how it worked for the proposals related to class fields).

@tc39/ecma262-editors WDYT?

[michaelficarra]

Without my editor hat on, I think you should merge the proposals. The sequence properties proposal is really only acceptable in conjunction with the changes introduced in the set notation proposal.

With my editor hat on, I don't think it should matter much. I'm not sure how we would do the syntax error on mixing sequence/non-sequence properties if the proposals get in separately, but I think we could make it work.

[markusicu]

We now have draft spec text for the combined proposal, advanced to stage 2, and noted that this proposal subsumes the other (see PR #29).