Klar RFCs

[ProCode-Software]

I've got most of the design features I wanted implemented, but there are still some features I want to have further discussion on because I can't decide how I want to implement them. For each undecided feature, I've opened requests for comments (RFCs) so you can input your feedback.

Goals for the language

• Progressive. Not afraid to move away from common design patterns in existing programming languages. I want Klar to fix many poor decisions from languages like JavaScript.
• Easy for beginners. I want to be able to teach this language to people with no programming experience. This means there shouldn't be too many features and rules to learn and remember.
• Safe. Minimal hidden crash vectors at runtime. Error handling is a big deal.
• Clean. Syntax should stay minimal and clean without ceremony.

See the full list of goals on the repo's readme.

The RFCs

See all RFCs at https://github.com/ProCode-Software/klar/blob/main/docs/RFCs.md and in the RFCs discussions category.

Dicussion links to each RFC:

• RFC #1: String literal formats #1
• RFC #2: Regex literal formats #2
• RFC #3: Resource management #3
• RFC #4: Should it be called `nil` or `none` #7
• RFC #5: Should methods be allowed on interfaces #8
• RFC #6: Publicity for struct fields/methods #9
• RFC #7: How to distinguish variable values from unwrapped variable declarations in `when` pattern matching #10
• RFC #8: Placement of pipeline values in function calls #11
• RFC #9: Private modules #12
• RFC #10: Should bitmask enums be added #13
• RFC #11: Iterators #14
• RFC #12: Should the compiler enforce identifier capitalization conventions #15
• RFC #13: Disallow tuples with 0 or 1 items #16
• RFC #14: How should leaking `Task`s be handled by the compiler #18
• RFC #15: Chaining assertions #19
• RFC #16: Readonly struct fields #20
• RFC #17: Readonly interface fields #21
• RFC #18: Should lists and tuples use 1-based indexing #22
• RFC #19: Errors #23
• RFC #20: Fallable list indexing #24
• RFC #21: `Result` methods #26
• RFC #22: Should `Task` and `Regex` be builtin types #27

Thank you all for your feedback!