C3 is balanced, please leave it alone :)

[alexveden]

I'm working on some project in C3 currently, I should say I impressed how C3 is balanced as a language. With some experience in C, I rolled into C3 almost without any issues. I love how C3 can be both safe and unsafe (like C is). It's a cool balance. I read full C3 spec and website a couple of times and I should say that there is no such thing I wanted to have added in C3. Everything is on its place, everything is just right. I would remove some things, but nothing to add to the core of the language. Simplicity is a feature of the C3 language.

When I read language design proposals, I often think to myself, that many of them are "nice to haves" and sometimes proposals just add another shortcut of doing things that C3 already can in other way. In my opinion, C3 language proposals should be filtered at least, we should consider the following questions:

1. is there a problem that currently C3 language couldn't solve (i.e. new proposal for solving new problem)?
2. what benefit for readability / writablility / debugability / clarity / safety the new proposed feature will bring to the language?
3. is already there a conventional way to solve the same problem with current C3 capabilities?
4. does proposed solution add a new semantics to the language? e.g. defer, @defer, #defer, %defer?
5. is the proposal intended to solve edge cases (say 1-5% of time)?
6. does the proposed solution add clarity (more explicit) or hides things or code flow (more implicit / new shortcut)?

The language couldn't keep all people happy all the time, there is an example of C++, which went to slippery slope of adding "nice to haves" all around. It eventually became a Frankenstein.

Maybe it is worth enhancing the macro system to let one make "nice to haves" for project specific tasks. Don't touch the C3 it's already cool :)

[lerno]

I don't want to worry you. Note that the @defer idea here is 6 years old at this point. That's why it's a "discussion" issue. It's not accepted into the language until it actually has "accepted". Maybe I should add a tag so it's clearer that it's far from being included. The idea is just to not forget about it.

[lerno]

See the loose idea label I added

[alexveden]

@lerno no problems absolutely. I really appreciate what you have done and doing with C3. I'm trying to look into future developments of the C3, and sooner or later with growing popularity you will face all sorts of people requesting different fancy features (because they present in other languages). So without well thought development policy, it would be harder to resit temptation of adding "nice to haves". I'm really afraid to end up with C3++ kind of situation.

I don't want to worry you. Note that the @defer idea here is 6 years old at this point.
See the loose idea label I added

My rant was not specifically on the subject of @defer, just it was discussed on discord at the time I was writing that post.

Maybe it's time to refine Roadmap https://c3-lang.org/getting-started/roadmap/

It's nice to meditate on philosophical questions about core language (excluding issues with stdlib and tools):

1. What current state of the language: what is lacking, what are the problems?
2. What is the end goal of the language development, where we want to stop?
3. What kind of enhancements appreciated? (My favorable options: combating ambiguity, more safe checks, more explicit stuff, less new entities and language constructs)
4. What is forbidden, i.e. never in C3 with reasoning (good example: https://c3-lang.org/faq/rejected-ideas/)
5. What could be done in user space (i.e. added via macros or stdlib)?
6. What is Zen of C3? (Zig has one https://ziglang.org/documentation/master/#toc-Zen)

p.s. So please don't take this personally, it's an attempt to figure out myself the place C3 could take in my toolbox. Everything is amazing so far.

p.p.s. So this is also a stream of consciousness, you may also tag this issue as loose idea too.

[lerno]

The main constraint of C3 is to be an evolution C. This means overall keeping C semantics and syntax. It also means that there is no particular need to introduce new ways of doing things that aren't in C. Some things have been added that are "new". Where interfaces is actually the biggest break with C tradition.

One other thing is that like C there isn't any plans to do C3 2.0 after C3 1.0 is done. Yes the stdlib should be expanded and updated over time, and the compiler itself can gain improvements, but the language should not need to change unless there are actual hardware changes the language needs to adapt to. So similar to C in the span of C89-C11 basically.

The things that are unresolved in C3 is whether there should be tagged unions. And tackling the enums with gaps in a good way. Everything else is just about removing corners and such. Like one example would be to allow $i[1] = 2, as this is the only "forbidden" operation for compile time variables right now. There are things like what $define returns errors on and what it tests for is undocumented and inconsistent. That needs to improve.

Then there are deprecations as well. But I am super happy when I find things to remove. I'm really excited about not having & in macros anymore – since that makes the compiler smaller and there is one less thing to learn to know C3. And in general the goal is to reduce the features in C3 now that people are starting to use it and one sees what kind of things are actually used and what things aren't. That doesn't necessarily mean they will be removed, as sometimes a feature covers important usecases that can't be implemented any other way (e.g. nextcase on a variable).

It's interesting that you raise the zen on Zig. This one is inspired by the Zen of Python as you might know. But more interestingly, it's quite frequently violated and the statements are fairly open for interpretation. I believe it has something like "together we serve the user", but it's unclear whether this is the programmer or the end user. One can suspect it's not the programmer given that Andrew has stated that he find it fine to make more work for the programmer to make things more explicit.

I think and hope that instead the language itself will end up as the answer to what the "Zen" of the language is, especially once it is properly pruned.

[alexveden]

Thank you for deep insight. We are on the same page. I think your post worth to be placed on main documentation page (roadmap or vision section), it's a strategic vision of the language. Conservativeness of a programming language is a strong proposition in modern world.

Then there are deprecations as well. But I am super happy when I find things to remove. I'm really excited about not having & in macros anymore – since that makes the compiler smaller and there is one less thing to learn to know C3.

That's also cool! Shall we open an issue here on GitHub with feature removal proposals? :)