[meta] Add a Prior Art section to the RFC template

[hgoldstein]

Like most engineering, language design heavily benefits from looking at prior art, and the vast majority of language features have prior art in a widely used programming language:

• Having similar features look and behave similarly helps widen the pit of success: it's good that a while loop in Luau and one in JavaScript work roughly the same.
• You can dodge known pitfalls with commonly implemented features: as of this writing we are using other implementations of classes to prove out the design for classes in Luau.
• Other languages with extensive RFC processes can provide hints and reasoning for direction on our RFCs, for example the FAQ about why Javascript uses the # sigil to mean private.

This can also apply to prior art for library functions. If we're adding a new math function, do other languages standard libraries have the same functions? The same constants?

This is worth adding a section to push all RFC writers in the right direction.

[InfraredGodYT]

I never thought about an approach like this, but I could see it being widely used across future RFCs.

[bradsharp]

Supportive of us adding this. We should also include a point about the existing language design being a key piece of prior art. For example if we introduced a new global called array then you would create one through array.create for consistency with table.create or coroutine.create rather than calling it something like array.init.

[nnullcolumn]

are there any examples of other projects which have this as part of their RFC process? /j

i am in support of this idea, but i think we could probably deliberate a bit over the organization and reading flow

[nnullcolumn]

"How do they compare and contrast to this design" might invite very shallow comparisons especially so late into the body. Maybe it'd be better to include this section below Motivation, above Design, and rework the wording to something along the lines of "What design considerations are unique to luau or that feature which are different here?" That way we flow from Motivation -> Similar Designs + Declaring Unique Constraints -> Design

[hgoldstein]

I think the idea of identifying unique design considerations is important, but my worry about that ordering is that it encourages a terse prior art section. I also think it makes sense to live along side Alternatives (e.g.: "an alternative is copy-pasting JavaScript's design"). I'll extend the language but keep its spot in the template.

[nnullcolumn]

my worry about that ordering is that it encourages a terse prior art section.

yeah, understandable. Just as a reader, I think I'd prefer to read

• "similar designs"

• "here's what's different about our situation"

• "here's what we're actually proposing"

in that order. reading a design proposal followed by design considerations feels like it invites unnecessary repetition people might not otherwise write in to begin with