Which parts of the Go API will break with the new evaluator?

[cueckoo]

Originally opened by @shykes in cuelang/cue#443

I know there is a major change to the Cue evaluator coming, and once it is shipped, all our wildest dreams will come true :) In the meantime, it would be useful to have a rough estimate of which parts of the Go API will be affected by this upcoming change, and which will remain stable.

In particular, will cue/load and cue/build break? And if so, what we should use instead? Even more specifically, I'm wondering if it's safe to write a custom loader, which would produce a cue/build.Instance without relying on cue/load. Would this work be jeopardized by upcoming API changes?

Thanks.

[cueckoo]

Original reply by @shykes in cuelang/cue#443 (comment)

Paging @mpvl as I think you're the only person who can answer this :)

[cueckoo]

Original reply by @mpvl in cuelang/cue#443 (comment)

I'm trying to keep things working as much as possible.

The cue/build and cue/load APIs will all keep working. Some of the APIs for this could use some simplification, but that would be a parallel effort. In general, I've mostly just rewritten the cue package and want to ensure that all the other packages don't change, assuming that if I need to change anything there, I'll likely break others. Especially the encoding/openapi and trim packages are pretty heavy users of the cue package, so these should be good litmus tests.

There are a few changes, though.

The following methods will be removed:

Value.BulkOptional: this was recently added to implement the move from old- to new-style definitions. This is a horrible interface, though, and will have to come up with something else.

Value.References: just because this has to be implemented from scratch and it has been deprecated for ages in favor of Value.Reference.

Here are some changes in semantics:

Instance.Build: will no longer "overlay" the build instance over the other instance, but rather unify it. The overlay proved to be a rather confusing concept. It was mostly to avoid namespace clashes, but new-style definitions solve this is a much more elegant way, so we can get rid of this.

I've ran into cases where CUE files are no longer working for the new evaluator, just because the old evaluator erroneously didn't catch bugs. There is not much I can do about that, of course.

Finally:

Of course, the old API is not great and doesn't fit the current CUE model anymore. The idea is to keep the old API working, though, and then implement a new API in parallel. The bulk of the old API has now been implemented in terms of separate packages, directly on the new evaluator, that can be used for a new API.