sync=False is a private, undocumented API. I think it's only found on the internal to_netcdf function in xarray.backends.api, not the to_netcdf method.

Currently, to_netcdf() will either return: - None if a path or file-like object was passed to to_netcdf(). - bytes representing the file's data if no path or file was provided.

In either case I think it could make sense to optionally replace the return value with a dask delayed object, which in turn evaluates to either None or bytes when computed.

What does ds.to_netcdf(...) usually return?

If sync == False the store is returned, otherwise nothing is returned.

The term future, when used in a Dask context, generally refers to something that is off computing asynchronously somewhere, rather than a token that holds onto a yet-to-be-submitted lazy graph.

Thanks for the clarification. I wasn't aware of that distinction but it does make sense.

What is store in this case?

A store is AbstractWritableDataStore, basically a wrapper class to allow us to read/write to various fileformats with various APIs under a common interface. Notably, each store has a writer attribute with a sync method that calls dask.array.store.

Another way to do this would be to have user code interact with the sync method directly:

```Python store = ds.to_netcdf('file.nc', sync=False)

store.sync calls store.writer.sync() which calls dask.array.sync

delayed_things = store.sync(compute=False) ```

This has the advantage of keeping the to_netcdf method a bit cleaner but does expose the AbstractWritableDataStore to user code which is typically not a public API object.

What is store in this case? Sorry not very familiar with how xarray does things.

The term future, when used in a Dask context, generally refers to something that is off computing asynchronously somewhere, rather than a token that holds onto a yet-to-be-submitted lazy graph.

What does ds.to_netcdf(...) usually return? Typically when we specify compute=False we usually return a dask-like thing, often a dask.delayed object that evaluates to what would have been computed normally.

@shoyer - Do you have thoughts on how this feature would present to the user? In #1811, I have added the compute keyword argument to to_netcdf and to_zarr and put a futures attribute on each store. So the workflow there would be something like:

```Python store = ds.to_netcdf('file.nc', compute=False)

dask.compute(store.futures) ```

Before I spend too much time on #1811, I want to get some buy in on the API for this feature.

In case anyone is curious, PR ( https://github.com/dask/dask/pull/2980 ) contains this work. Feedback welcome.

Just to give a brief synopsis of what we are working in Dask in case it is valuable for this or other contexts, have given an overview of the relevant work below.

With Matthew's help am trying to add a keep argument to da.store. By default keep=False, which is the current behavior of da.store. If keep=True however, it returns Dask Arrays that can lazily load data written by da.store. Thus allowing the stored result to be linked to later computations before it is fully written. The compute argument of da.store affects whether to submit the storage tasks immediately (adding Futures into the resultant Dask Array) or whether to hold off until a later computation step triggers it.

This sort of functionality could be useful for a variety of situations including the one Matthew has described above. Also this could be useful for viewing partially computed results before they are totally done. Another use case could be more rapid batching of computations with many intermediate values. There is also an opportunity to re-explore caching in this context; thus, revisiting an area that many people have previously shown interest in.

Yes, this sounds like a natural improvement to me!