Normative: Redefine CatchParameter as FormalParameter

[chicoxyzzy]

This change removes default value restriction for catch parameter.

Closes #1121

[allenwb]

Did you review all of the static and runtime semantics rules associated with FormatParameter to make sure the will work for CatchParameter. They are probably fine, but it needs to be proactively verified.

[littledan]

@chicoxyzzy Thanks for preparing this patch. At a glance, it seems correct, though I'm not sure why we should bother having a CatchParameter production at this point rather than just using FormalParameter directly. This would require updating many more little parts of the spec, unfortunately.

Would you be interested in writing test262 tests for this change? (I think the test wouldn't change regardless of whether you take that editorial suggestion I made above.)

[chicoxyzzy]

@littledan sure, no problem. I will create PR in test262 repo within the next few days.

[anba]

I know Allen mentioned in #1121 to use FormalParameter, but I still don't see why we can't use BindingElement directly.

[chicoxyzzy]

@anba I think that using FormalParameter could be guarantee of consistency

@littledan IMO it's better to keep CatchParameter name because we also have a lot of notes about CatchParameter behavior in spec

[littledan]

I don't have a strong opinion about this editorial question, but in general, I don't think patches like this need to use a minimal number of lines of spec changed as a goal. It would be a little bit of work, but it'd be fine to update all the usages of CatchParameter, even though it's a bigger patch.

[leobalter]

what happens when the initializer is/has the binding name?

try {
  throw undefined;
} catch (x = x) {}

[ljharb]

@leobalter i think that'd just be the same as (x), and altho we could forbid that, we couldn't likely forbid catch(x = (x)) or catch(x = (0, x)) so it might end up being a linter thing (like throw throw)

[leobalter]

Let me expand this a bit more:

var x;
try {
  throw undefined;
} catch (x = x) {}

var y = 42;
try {
  throw undefined;
} catch (x = y) {
  let y = 42;
}

try {
  throw undefined;
} catch ([x = y, y] = x) {}

In functions we have the IteratorBindingInitialization to solve these issues.

I believe the catch clause evaluation should get some 👀 as well.

[chicoxyzzy]

I'll take a look at it

[anba]

@anba I think that using FormalParameter could be guarantee of consistency

Can you clarify what you mean by "consistency"? FormalParameter is more or less only an alias for BindingElement, when ignoring its additional static semantics. And for the runtime semantics it seems unlikely we want to use https://tc39.github.io/ecma262/#sec-function-definitions-runtime-semantics-iteratorbindinginitialization here.

[chicoxyzzy]

Sorry, I was too busy at work. I'll try to get back to this in next few weeks.

[ljharb]

@chicoxyzzy have you had a chance to get to this?

[chicoxyzzy]

I'm trying to make python test generation tool work, but no luck yet

[chicoxyzzy]

Do I have any chance to find a champion who can present this normative change to the committee? I'm going to make another attempt at tests soon.

[ljharb]

@chicoxyzzy Once tests are written I'm happy to present it to the committee on your behalf; I'll probably be able to do that in July.

[ljharb]

@chicoxyzzy ping; we've still got some time, but if you can get those tests written I can add this to the July agenda :-)

[chicoxyzzy]

Unfortunately I won't have time for that until the end of this week 😞

[ljharb]

@chicoxyzzy that would work just fine! looking forward to it.

[ljharb]

The committee discussed this today and could not come to consensus on merging the PR - there was skepticism about the value of this change, and concern about it being confusing. If @chicoxyzzy or anyone is still interested in this change, a full proposal would be appropriate.

I'll close this PR, but we can reopen it if this becomes a proposal that advances.

[chicoxyzzy]

Yes, I'd like to create a proposal repo later.