Should we drop private-use annotations?

[eemeli]

During today's call, we resolved to drop forwards compatibility from the stability policy, and to remove all reserved syntax.

private-use-annotation was originally added to the spec in #404 at least in part due to us adding reserved-annotation. As we're now removing the latter, we should reconsider whether to remove the former as well.

Can we imagine use cases for private-use annotations that would not be equally well served by function annotations?

[aphillips]

There are three mechanisms in play here:

• reserved statement uses an undefined keyword:

  .foo {does something?} {{}}

• reserved annotation uses a reserved sigil for some unknown (future) purpose:

  ~foo {{does something}}

• private-use annotation is implementation defined:

  &implementation-specific {whatever} {{}}

We took away the first one today. I am not sure, but we might be thinking of taking away the second one. This issue asks (obviously) about the third one.

I think there is value in:

• reserving the sigils that might be used in the future
• providing an implementation-specific extension mechanism that is constrained in its syntax

However, I could be persuaded to remove both. We do provide namespacing for functions and these are implementation (and even installation) specific. Future keyword addition (i.e. "reserved" statements) would be my preferred mechanism of extending MF2 vs. using additional sigils.

[aphillips]

Can we imagine use cases for private-use annotations that would not be equally well served by function annotations?

Actually, I got the above wrong. PU annotation is inside of an expression only. So, no, I can't think of a use for this given that we have namespacing. We should dump it.