Symbol name clash

[bart9h]

Raylib uses generic names like Font, Music, Sound, Shader, Model, Texture, BoundingBox, Matrix, BeginDrawing, PlaySound, etc. These names could also be used in anywhere, and should be avoided in a library, because it can lead to clashes. There are other (mostly closed) issues here about compilation errors that are caused by this.

C++ has namespaces, but as raylib is written in C, maybe you should consider using a prefix for all the names in the library? Maybe raylib_, Ray_ or something like that.

For backward compatibility maybe provide an header file that does #define SomeName Ray_SomeName.

[raysan5]

I'm afraid this is a know issue and can be avoided not including raylib in the same compilation unit as other libraries with colliding symbols. I have no plans to change raylib for the moment.

[orcmid]

@bart9h : For backward compatibility maybe provide an header file that does #define Ray_SomeName SomeName.

Did you mean #define SomeName Ray_SomeName? Either way, I don't think it eliminates clashes with the undecorated name.

I don't know any solution to this at the Native C Language level beyond following Ramon's advice on isolation of dependencies via compile-unit separation.

[bart9h]

Did you mean #define SomeName Ray_SomeName?

Yes, I did.

[spillz]

I think the current C naming scheme is unfortunate. Using a common and short prefix like rl would both avoid name clashes with user code and would be an important readability and discoverability win (e.g., in any decent IDE you would type rl and be prompted with available Raylib symbols). Most popular modern open source C libraries follow this practice.

But someone who really wants this now could presumably create a prefixed C wrapper in a .c file that redefines all the symbols with prefixed names and an accompanying prefixed header that would essentially hide the unprefixed names in user code that only includes the prefixed header. That's an untested proposition but would perhaps offer a migration path should you reconsider @raysan5.

[raysan5]

@spillz no plans to add prefixes to raylib. Most collisions can be easely avoided.

[spillz]

Thanks for clarifying because your "for the moment" at the end of the prior comment appeared to be leaving the door open. I am not so concerned about collisions at the machine level, just in the old brain box, so this is a blocker for me using this as a C lib. Fine though for python etc languages where namespaces are automatically defined at the package/module level. But this is your lib and you choice, tastes vary etc. so you won't get further argument from me.