Implement WeakReference, Finalizer and NativeFinalizer

[mraleph]

This issue tracks the implementation of the WeakReference, Finalizer and NativeFinalizer classes (issue, language proposal).

Implementation tasks

• Add WeakReference, Finalizer and NativeFinalizer to core libraries #47773
• Add tests for WeakReference, Finalizer and NativeFinalizer #47774
• Implement WeakReference, Finalizer in dart2js #47775
• Implement WeakReference, Finalizer in dartdevc #47776
• Implement WeakReference, Finalizer and NativeFinalizer in VM #47777
• Implement support for creating isolate independent native functions code in dart:ffi #47778

[devoncarew]

@lrhn - I understand you have a CL in progress to add the above types to the core libraries? We should probably hold off on landing that until we know when the implementations will be ready to land (in the Feb release or the May one).

@mraleph - do you have a rough sense for when the implementations might be ready? Or, whether we'd be ok w/ landing the types, and one implementation, but have other implementations throw on use at runtime (whether we want a consolidated landing or are ok w/ a staggered one)?

[mraleph]

Let's target the release after the next one to give us more time to iron all the issues.

[mraleph]

@devoncarew "February" milestone due date is set to 6th of March, which is a bit of confusing. When is the actual cutoff date for the implementation for "February" release?

[devoncarew]

Yes, we had some discussion in the dart scrum about this once or twice. There's now a bit more text in the milestone name to help clarify things, but definitely some confusing bits remaining.

The milestones are named after the month in which the work is done. We then branch immediately after the calendar month, generally the monday of the first full week of the following month. So the February milestone branches in early March.

Since we're not targeting the next stable (2.16, releasing in early Feb.), putting this issue in any of the 2.17 milestones is reasonable.

[devoncarew]

@lrhn - it sounds like we're targeting 2.17 for this feature generally. My guess is that we shouldn't start landing new public API here until after the branch cut for the next stable; the branch week for that is the first full calendar week of Jan.

[devoncarew]

@lrhn @mraleph @sigmundch - from a discussion at the Dart scrum:

We're currently planning to not land the API changes here until after we branch for the next stable (Jan 4th), then work for the next ~3 months to get the implementations in place. This does mean that we're delaying engineering here for a few weeks in order to be able to land the whole implementation in one stable release. Call this option 1.

There were two other alternatives that we discussed:

option 2: land the API change, mark it as experimental, and have an initial implementation that just throws when used. The implementations could happen at their own pace, and we could remove the experimental annotation once everything was ready.

option 3: land the API in a private library, allow implementations to start work, and make the API public later; aka, start private, and graduate to a public API

Given that there's not much development time between now and Jan 4th, we were thinking of just continuing to go with option 1 - delaying the API change CL. But we wanted to get other people's thoughts as well; cc @mraleph @lrhn. From the discussion, Siggi didn't have any concerns that the web impls. would not be able to get done within the context of the Dart 2.27 release.

[dcharkes]

This does mean that we're delaying engineering here for a few weeks in order to be able to land the whole implementation in one stable release. Call this option 1.

Copy pasting in the APIs to dart:core and dart:ffi from the language proposal is easy. So engineering can already start. (With some merge conflicts later, and not having a host of tests yet.)

I'm fine with all 3 options.

[lrhn]

We already have a CL for the dart:core declarations: https://dart-review.googlesource.com/c/sdk/+/221502
(Now we just have to keep it merge-able until January 4th, with every change to CHANGELOG.md. 😱).

[devoncarew]

OK, thanks; lets keep the CL out (but not landed) until on or around Jan. 4th (more specifically, once we've definitely branched for the next stable).

[fzyzcjy]

Hi this is a really helpful feature that will simplify programming! (Related: fzyzcjy/flutter_rust_bridge#243)

[fzyzcjy]

Hi, I wonder when will Dart finalizers be available (stable)? Thanks!

[mraleph]

@fzyzcjy see the milestone attached to the issue. We are currently targeting 2.17 release.

[fzyzcjy]

@mraleph Thank you! (Indeed I wonder when Flutter stable can use it... Given that 2.17 is beta, I guess maybe still need to wait half a year?)

[devoncarew]

@lrhn - we've effectively branched for the next stable; feel free to land your API changes at any time.

[gmpassos]

How finalizers will work?

Please don't make it like the java finalize methods. The finalizer paradigm is from the context of who is using the object and not from the context of the implementation of the object/class.

A class can be used by many different contexts, and each different contexts will demanda a different finalization. Don't think that a Finalizer is just to dispose some resource, like the Closable pattern.

Sorry if I'm saying something that is already being addressed, but I'm just guessing some issues based in past experiences.

[gmpassos]

Any plan to implemente SoftReference? They are not very different from a WeakReference.

SoftReferences are very important too, specially when building large memory softwares and some optimization patterns. They are amazing for transparent caches and also for memoization patterns.

[mraleph]

How finalizers will work?

There is a link to the language proposal in the issue: https://github.com/dart-lang/language/blob/master/accepted/future-releases/1847%20-%20FinalizationRegistry/proposal.md

They will work like Cleaner.

Any plan to implemente SoftReference? They are not very different from a WeakReference.

No plans at the moment.