Some suggestions.

[g40]

Would be more than happy to help out with these.

1. Add a section to the readme which details how to extend the silicon.h API? i.e. how to add C analogues of existing Obj-C APIs?
2. Clarify what needs to be tracked in terms of object ownership (autorelease pools etc)
3. Maybe add a link to the Apple metal-cpp implementation which contains some very useful C++ classes for managing stock ObjC types. (https://developer.apple.com/metal/cpp/)

[ColleagueRiley]

1. That is a good idea, considering it is relatively easy and formulaic to do.
2. Also a good idea
3. This is not a C++ project, I also don't know much about the quality of the said library. To be honest with you, I am of the belief that all system level APIs should be written in C. This makes the library far more portable and easier to bind into higher level languages.

[EimaMei]

To add further comment on the 3rd point, Silicon was originally made for two main reasons: for it to be in C and for it to make the API more clear by naming every function <Class>_<functionName> instead of depending on inheritance. If I wanted to keep the old way, I would’ve probably written the library originally in C++, but I abstained as that part makes Cocoa unnecessarily more complicated and complex than it needs to be. Also, this allows for easy language bindings to possibly other languages, not just C.

Another thing is that Silicon is a bit more than just a direct Cocoa port. It’s trying to make Cocoa more C like, where general data types like NSString or NSArray are replaced with actual 100% compliant C-data types (being siString and siArray). As such you realistically cannot use something like Apple’s C++ port of the Foundation header in conjugation with Silicon. Both are trying to do two different things and it doesn’t make too much sense to link it here (I mean, what would it even help with?).

[ColleagueRiley]

Additionally, I would think C++'s longer compile time makes the single-header file less practical.

[g40]

Hello. Good that we are all up for points 1 and 2 :)

re c++ and metal. Allow me to clarify any misunderstandings. Silicon-h is a C library. That is great and should never change. Building upwards I could easily imagine another layering that applied the usual C++ resource management to C libraries. That’s all. The metal reference is a) simply there for anyone else unaware of its existence, and b) a waypoint for my own code.

[ColleagueRiley]

I don't really like C++'s resource management, but I suppose that's unrelated.

But also, I would imagine the main use of Silicon would be for things such as my library RGFW, in which the end user doesn't have to worry too much about managing Silicon's resources because the library abstracts the use of the other APIs for the user.

Point being, I think both libraries have two different goals. Silicon is more about making Cocoas the low level API it should be in C. While the C++ library is more so about keeping it very high level and just doing a light port to C++. I think the inclusion of a more functional way of interacting with the library and the use of siArray and const char* show this point of very well.

Oh, I also created the readme section which details how to extend the silicon.h API. Although I don't really like how it's written. Feel free to send an issue if you can think of something to chance. Though, I think I'll probably just have Eima read over it.