Aster crate

#21

Having aster in tree doesn’t just make it easier to fix aster – it makes it impossible to have a broken aster. Even if aster were out of tree but “tracked” it’s still trivially easy to have a broken combination of aster version and nightly version. This is fundamentally a function of the stuff that syntax extensions have to use being incredibly volatile.

As I see it there are only two fundamental solutions to this problem:

  • provide a more stable interface (more seriously push against changes to libsyntax, provide aster in-tree as a stable interface, or provide some other stabler interface for syntax extensions to target). Note that this does not mean stabilizing syntax extensions – it just means stop breaking them constantly.

  • provide a way for libraries to specify dependencies on the compiler version (so you magically always get the “right” aster for your nightly). This is a worse option imho because now you need to hunt for a nightly sweet-spot to resolve your deps. Having less volatile syntax apis means that you’re more likely to get “lucky” and have everything keep working (because nothing important changed). Also less work for syntax extension maintainers!

I understand that the compiler is undergoing massive reform, and not breaking everything everywhere is a pain. However I would implore you to seriously prioritize limiting the breakage on these APIs ASAP. It doesn’t mean you need to settle on the perfect design. It just means tweaks to the public API should be less frequent. This also doesn’t have to be today or tomorrow – just please, sooner rather than later.

closed #22

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.