first blog post's up on my site! an expansive, semi-coherent introduction to my funny little C++ successor language, comune.
https://estrobiologist.github.io/2023/06/06/introducing-comune
@soqb thanks so much! it means a lot :)
and to be clear, the spacing in `T mut& a` is mostly down to preference - `T mut &a` is just as valid. initially the syntax was closer to Rust/west-const C++ (think along the lines of `mut& T`), but i shit you not, trying to parse that kind of syntax single-handedly converted me to being an east-const fan LOL
@estroBiologist oh that’s good to hear. i suppose it is a bit early in the project to be suggesting formal style guidelines…
HOWEVER, as always i’m immediately quids in for predominantly snake_case identifiers (including in type names) because it looks real nice.
@soqb under my totalitarian reign as BDFL, snake_case functions and PascalCase typenames will be MANDATORY. resistance is FUTILE
@estroBiologist but_it_looks_so_nice_😨
@soqb c++ gave me snake_case typename trauma, i need the modern feel of PascalCase or i start getting flashbacks to that godawful syntax
@estroBiologist > in type theory, this is known as the bottom type, but i am NOT calling it that are you CRAZY
any identifier that looks like a keysmash or includes 🥺 should be an alias for `never` 
/j
jokes aside comune looks cool af, this got really excited as it read the post 
definitely going to try it out later
@estroBiologist this is very cool! I am glad to see some solid choices up front like lowering to LLVM IR, yay! I am beyond excited at the idea of borrow checking and Rust semantics and actual C++ interop.
If you’ll indulge a question, why do you have lvalues implicitly convert to a reference instead of requiring a borrow op as per Rust? I noticed it in the example ‘new (c) TheType()’ thing.
Also you didn’t mention it I think but I did see some Clone and Copy trait impls. Do objects move automatically when passed as args (or convert to refs sometimes?) or when used as the object of a method call which receives ‘self’? Are there… move constructors? I hope not they ruined the world but then how will it cope with c++ if not?
Thanks! Keep this up!
@blinkygal thanks so much!
the reasoning behind implicit borrowing comes down to simplicity, consistency and conciseness - Rust already implicitly borrows in some prominent places (i.e. method calls), and since comune's reference system is already much more simplified, i decided to do away with the cognitive overhead and have the compiler just Figure It Out.
@blinkygal and yep, non-Copy types are moved automatically, unless passed to a ref parameter or assigned to a ref binding. no move constructors in sight - which does mean types with destructors must be wrapped in "guard" types (provided by the standard library, one such concept shown below) when passed to C++ code.
this is one of the compromises i'm the least happy with, but i think it still beats having move constructors.
@estroBiologist I see, it’s a little like an Option. How would a C++ Type be moved in comune? Would they only be accessible as references?
Btw for DropGuard, operator= may want to drop() if it is live when called? And using memcpy instead of new to make the union member active (from the move ctor) is UB unless the type has a trivial default constructor.
@estroBiologist And everything beats move constructors and having to call destructors on moved from stuff! I would sacrifice a lot for that. 😊
@blinkygal i'm honestly undecided on how to handle C++ types in comune code - one option would just be to treat them as any other type, ignoring move c'tors and exposing non-trivial copy c'tors as Clone impls, but i could imagine that breaking some more esoteric types. it might be best to play nice and generate the appropriate c'tor calls for C++ types - genuinely not sure
(& thanks for pointing that out! i'll be sure to fix it)
@estroBiologist yeah skipping the move constructors would break anything self-referential. Like std::string with SSO.
Love what you’re doing :)
@estroBiologist this is really fucking good!!! i honest to god shed a tear at one point - `new&` is such an excellent Rust/C++ synthesis.
one nitpicky point is that i (entirely on my own) think, considering references are not types but bindings, rather than `T mut& a` we should have one of `T mut&a`, `T &mut a` and `T mut &a`. the current syntax strongly reminds me of `T *a` pointers, which don’t work for me because `T*` is a separate type and not a binding (roles reversed ofc).