[breaking change] Remove Dart_UpdateExternalSize and Dart_UpdateFinalizableExternalSize from the Dart C API

[a-siva]

Change Intent

This breaking change proposes removing

Dart_UpdateExternalSize
Dart_UpdateFinalizableExternalSize 

from the Dart C API as they are not being used by any of the embedders.
Please see #42078 for more details and discussion
in https://dart-review.googlesource.com/c/sdk/+/256025

Justification

Code cleanup (removing unused code from the sources).

Impact

We believe nobody uses this API and should not impact any users or embedders.

Mitigation

No mitigation required

[a-siva]

//cc @dcharkes @rmacnak-google @bkonyi

[kevmoo]

SGTM!

[itsjustkevin]

@a-siva could we approach this by deprecating the members in question for a cycle or two and announcing before fully removing them?

We may not have a complete understanding of who is utilizing the above APIs, this would give users time to migrate to another path.

[dcharkes]

I have no objections, but please ensure to bump the major version to 3 in runtime/include/dart_version.h.

This will create a breaking change for everyone using dart_api_dl.h and create a before and after. (Not only the people using these symbols.)

Justification
Code cleanup

I'm not sure if this is worth the hassle of bumping the dart_api_dl.h version.

How much code can we clean up with this change?

The infrastructure itself for removing external size is used in native finalizers as well, so this is only about removing the symbols from the dart_api, correct?

@itsjustkevin these are symbols in C/C++, not in Dart.

cc @mkustermann, @mraleph for visibility

[itsjustkevin]

Thanks for clarification @dcharkes!

Plugging in @Hixie @vsmenon and @grouma for breaking change approval.

[grouma]

SGTM

[Hixie]

fine by me. (fyi @zanderso @dnfield)

[dnfield]

Sgtm

[zanderso]

sgtm

[mkustermann]

I have no objections, but please ensure to bump the major version to 3 in runtime/include/dart_version.h.

This will create a breaking change for everyone using dart_api_dl.h and create a before and after. (Not only the people using these symbols.)

That's a good point. There's a few options

• increasing version number: breaks all apps that use dart_api_dl.h
• not increasing version number: only people actually using the symbols (which there may be none) are affected
• only remove them from Dart C API and not from dart_api_dl.h, possibly making them NOPs
• keeping status quo

IMHO we should choose a solution that doesn't break perfectly fine code.

[dcharkes]

• only remove them from Dart C API and not from dart_api_dl.h, possibly making them NOPs

This option also crossed my mind, we would be lying in our semantic versioning then regarding these two specific symbols, but it might be the least worst option.

• not increasing version number: only people actually using the symbols (which there may be none) are affected

That's a bad idea if we do actually remove the symbol from dart_api_dl.h, it would break binary compatibility. Did you mean something else?

IMHO we should choose a solution that doesn't break perfectly fine code.

++

[bkonyi]

Is there any reason we can't just mark these APIs as deprecated and make them no-ops until we're ready to do a larger cleanup?