Requiring C23 for a library header is a great way to guarantee nobody will use your code for long time.
I still write nearly ANSI compliant C for simple embedded things. Because somebody might need to figure out how to rebuild it in twenty years, and making that person's life harder for some syntactic sugar isn't worth it.
Even C99 can be a problem: for example, C99 designated initializers are not supported in C++. If your header needs to support C++ you can't use them (C++ forces you to initialize every field in the structure in order if you do it that way).
Very few people are using C for `quality-of-life features`. I'm fairly certain I've never even seen any C23 code, is it supported by many compilers or C tooling? One of the great things about C is that it is fairly easy to write code that runs everywhere and for a library that is especially important. There are many who just stick to C89.
Well, this library provides the core functions for classical, Western music theory (scales, keys, intervals, etc.). So any ideas that needs to understand or generate these structures could use them. Some examples off the top of my head:
- Music theory education tools
- Music generation (and the outputs could be transformed to MIDI format for example)
- Piano chord finder
So you can generate the d dorian scale and it outputs d e f g a b c d?
Whats the target audience? A good musician knows the scales by heart (and also how they sound/feel) and for the others it's unclear to me what they would do with music theory they don't really understand.
I think you're looking at this the wrong way around. A human might know the notes of a D Dorian scale, but a computer doesn't. If you've ever selected the key of D major in any music creation software and it's shown you a stave with two sharps then the computer was using a library like this.
For your second thought, I'm not really sure I understand the point.
Since this is a library, it can power any application that needs to understand or generate these abstractions. So to expand on some options I gave above:
- You can create a program that generates a piece in the style of a Bach cantata for example, using this library as the backbone.
- If a teacher wanted to create a tool to educate kids about scales for example, it can use this library as a backbone.
If you don't have a practical use case, the probability that there is one AND that it will use your library (instead of building its own, adjusted to their needs) is next to zero.
(I have been there more than once a long time ago)
Edit to add: and it's not to blame. Just there are more and more libraries popping up these days, without a clear use case, even their own. Which is totally fine as long as they are clear about not having one.
Ah yes, that is by design. This is because it supports more than a double sharp / double flat (eg triple sharp, quad sharp, etc). The enums are there just for the most common values so it's easier to read.
As for second, that's a good point! Would definitely make readability better, thanks.
As someone who only has used C in conjunction with Rust...
Given that it is 2026, what are some of the thoughts that go into choosing C99 vs C23, which I presume has more quality-of-life features?
Requiring C23 for a library header is a great way to guarantee nobody will use your code for long time.
I still write nearly ANSI compliant C for simple embedded things. Because somebody might need to figure out how to rebuild it in twenty years, and making that person's life harder for some syntactic sugar isn't worth it.
Even C99 can be a problem: for example, C99 designated initializers are not supported in C++. If your header needs to support C++ you can't use them (C++ forces you to initialize every field in the structure in order if you do it that way).
> C99 designated initializers are not supported in C++.
They are, finally, part of C++20.
Very few people are using C for `quality-of-life features`. I'm fairly certain I've never even seen any C23 code, is it supported by many compilers or C tooling? One of the great things about C is that it is fairly easy to write code that runs everywhere and for a library that is especially important. There are many who just stick to C89.
The quality of life is “it compiles nearly everywhere with the first toolchain you can get your hands on”.
As usual, clang and gcc have great support, intel ok, msvc no.
C11 is probably the newest that’s widely adopted.
known quantity. UBs well understood. tooling.
Yes, you sit at that piano every Sunday morning and play Mahler for Maris. But you hate Mahler. Besides Maris, who doesn't?
What is the purpose of this and how would I use it (as someone who actually knows a lot about music theory and C programming)?
Well, this library provides the core functions for classical, Western music theory (scales, keys, intervals, etc.). So any ideas that needs to understand or generate these structures could use them. Some examples off the top of my head:
- Music theory education tools - Music generation (and the outputs could be transformed to MIDI format for example) - Piano chord finder
and similar.
So you can generate the d dorian scale and it outputs d e f g a b c d?
Whats the target audience? A good musician knows the scales by heart (and also how they sound/feel) and for the others it's unclear to me what they would do with music theory they don't really understand.
I think you're looking at this the wrong way around. A human might know the notes of a D Dorian scale, but a computer doesn't. If you've ever selected the key of D major in any music creation software and it's shown you a stave with two sharps then the computer was using a library like this.
There is a function for that, yes.
For your second thought, I'm not really sure I understand the point.
Since this is a library, it can power any application that needs to understand or generate these abstractions. So to expand on some options I gave above:
- You can create a program that generates a piece in the style of a Bach cantata for example, using this library as the backbone.
- If a teacher wanted to create a tool to educate kids about scales for example, it can use this library as a backbone.
The question is: what is the use case?
If you don't have a practical use case, the probability that there is one AND that it will use your library (instead of building its own, adjusted to their needs) is next to zero.
(I have been there more than once a long time ago)
Edit to add: and it's not to blame. Just there are more and more libraries popping up these days, without a clear use case, even their own. Which is totally fine as long as they are clear about not having one.
>So you can generate the d dorian scale and it outputs d e f g a b c d?
lmao
Love the point of 100% test coverage.
Nitpicking:
https://github.com/thelowsunoverthemoon/mahler.c/blob/4ebfe8...
Should that type have been mah_acci instead of int? mah_acci doesn't seem to be used anywhere.
Also, have you considered using (edit) designated initializer syntax for some of the function calls that take in structs as arguments?
https://cppreference.com/w/c/language/struct_initialization....
Ah yes, that is by design. This is because it supports more than a double sharp / double flat (eg triple sharp, quad sharp, etc). The enums are there just for the most common values so it's easier to read.
As for second, that's a good point! Would definitely make readability better, thanks.