[core] Should functions that receive enum values use the enum as argument type?

[albertvaka]

[core] Should functions that receive enum values use the enum as argument type?

[raysan5]

@albertvaka This is a design decision to use simple int for enums. Agree with @colesnicov @RobLoach commented points.

Just for completion, here a list of some unpopular raylib design decisions (critisized multiple times):

Technical decisions

• No prefixes
• No pointers, data mostly passed by value
• No typed enum values
• No size_t for sized values
• No return error codes (with some exceptions)
• No advance/engine features: lighting, PBR, physics...

Non-technical design decisions

• No formal docs: use cheatsheet + examples
• No backward compatibility between releases (minor breaking changes)
• No youtube tutorials
• No reference books

[colesnicov]

Yeah, you'll see that a lot. Previously, enums were somehow not used in 'C', definitions were given priority and they are numerical.. Because the compiler doesn't care if it's an enum or a define, both are numerical.. C++ is strictly type-controlled, 'C' is a little more permissive

[RobLoach]

While they're somewhat the same, using an int makes it easier to bind to other languages. Parsers don't need to map the enums before use, and the compiler doesn't mind.

[colesnicov]

@raysan5
So, since it's already here, I'll ask if you have a summary somewhere, why don't you use

• pointers but pass by value
• why no prefix?

As for lightning, physics,.. that's clear. You didn't make a new Unity, but a lightweight cross-platform library that makes it easier to create simple games...
Error codes, what could go wrong? Am I entering the wrong data? I have to take care of that myself.
I personally don't like using `size_t' either, it doesn't always have to be suitable.
You don't have to write it down here, but if you've already had a discussion like this somewhere and could post a link, I'd read it. Just out of curiosity.

[raysan5]

@colesnicov Most of the original desing decisions were for simplicity. Library was intended to teach art students with no previous coding experience so I tried to minimize as much as possible elements that could add complexity to syntax and code.

About prefixes, the course syllabus was raylib --> MonoGame --> Unity so keeping the same naming conventions between the 3 technologies was a good idea; my previous gamedev experience was also with MonoGame/C# and personally I didn't like prefixes.

About error codes, it looked way more simple, clean an intuitive to me that a LoadTexture() returned a Texture instead of an error code and a texture by reference. Same for other similar functions.

As said, most of the decisions were taken towards simplicity, despite I understand that most advance programmers could find them somewhat unconfortable.