Thanks! I don't think we should lose the braces. Braces help avoid mistakes when refactoring/copying/pasting code, and they make the language look more familiar

Thanks! I don't think we should lose the braces. Braces help avoid mistakes when refactoring/copying/pasting code, and they make the language look more familiar to people coming from C-like languages, which I think are large enough advantages to justify having them. I'm considering adding some meta-programming/reflection capabilities in some form, if they don't increase the complexity of the language too much. Lisp-style macros would be a possible approach, compiler plugins would be another. The latter approach might be easier to implement though. A package manager will be out of scope for at least the near future, but long term it would be great to have one! Re: owned pointers. I'd recommend that people look into more coarse grained memory management strategies first (e.g. arena allocation), and use one of those if possible. However, these strategies definitely have their limitations, which is where alternatives like owned/shared pointers could come in. However, to implement a "proper" owned pointer, e.g. an alternative to std::unique_ptr<T>, we would need destructors (which Muon will never implement) and move semantics (of which there is a chance that Muon _might_ implement it, but probably not anytime soon). With move semantics we can perhaps create a lighter weight owned pointer that is still useful; I'll have to experiment a bit to see how that would work out.