@philipturner Thanks for offering to take it on! If you are just starting to make contributions to Swift compiler, a best practice might be to give us a heads-up (and ideally a rough proposed solution) before assigning the ticket to yourself, because most autodiff issues are not trivial.

I'll go ahead and remove the assignment since the PR is incorrect, but do let us know if you want to take this on again. The cross-import overlays are really great to have, since they will remove `_Differentiation`'s dependency on Glibc/Darwin/ucrt. You can read the pitch here to see whether you want to spend some time to tackle it.

I don't know of any other issues assigned to you, but I believe you can self-unassign, too, by setting assignee to "Unassigned".

Sorry, I do not. Looks like https://gist.github.com/beccadax/8f35216340e829efa5e9c1fc090fda09 is the updated proposal.

Again, I'll limit my discussion here to the Swift Open Source Project (i.e. autodiff itself, not its adopter libraries you mentioned). This cross-import overlay task is not something I or anyone can "call off", as it is a release requirement.

For smaller starter tasks, I'd recommend reaching out to @BradLarson.

@philipturner Off the top of my head, one issue that could be a good starting point, if you're looking for general autodiff issues to work on, is SR-14056. Extending the conditional conformance to `Differentiable` to more collection types within the standard library should be fairly approachable and would have practical benefits for users of differentiable Swift. I believe this is a follow-on from the old TF-1199, which I think was just asking for the addition of a conditional `Differentiable` conformance to Dictionary.

For example, we have local implementations of a Differentiable conformance for Dictionary and a couple other collection types in our model code, and that consists of a bunch of repeated boilerplate code to support those cases. Supporting more collection types would allow us and other users to delete the code for our versions of this.

If a cross-import overlay is the right design decision to plan for the future, I don't have a huge problem with enabling a temporary build flag while the feature is being prototyped. We've done that intermittently for other language features. I'm guessing tensorflow/swift-apis would also be impacted.