string overloads

[crazymonkyyy]

raylib uses c strings blah blah

some generated code:

stringoverloads.d.csv.json.txt
findcharstar.d.txt

[crazymonkyyy]

as written theres a bug with handling string litterals

import std;
void cstring(const(char)*){}
void dstring(string){}
void mixedstring(const(char)*){}
void mixedstring(string){}
unittest{
    string bar="bar";
    cstring("foobar");
    string foo="f";
    foo~="oo";
    dstring(bar);
    dstring(foo);
    mixedstring(foo);
    mixedstring(bar);
    mixedstring("foobar");
}

mixedstring("foobar"); works IF AND ONLY IF, mixedstring is in the same overloadset, and its unclear to me if its even possible to disambiguate string literals from strings

for my solution I copy and pasted my string overloads into package.d

https://github.com/crazymonkyyy/raylib2025/tree/master

[schveiguy]

I believe accepting a string literal via a C string parameter is considered a conversion for purposes of overloading. So it will prefer the D version first.

In any case, I would probably accept string overloads as long as they do not use D facilities. That is, it's OK to malloc a string, send it into a function, and then free the string. But I don't want to use GC-allocated C strings. That will happen in draylib.

This does mean that it can't just be a blanket overload for all functions, because some functions might store the char* expecting it to last forever.

[crazymonkyyy]

given its been in a bad state for several years and youve been talking about doing a major port for a while(and such a thing will just take time), I think you should consider shipping a bandaid even if theres "buyer beware" consideration, for the main usecases it will probaly work or they will be found quickly

this mainly effects the dub people cause well... I just point sane people to my project template but that is likely 75% of users and your students wont

[schveiguy]

The focus of this is to be a binding to the C project. Yes, there are some D enhancements, but I don't want to go too far. As it is, it's very easy to keep up with the existing release, making a new release takes about an hour based on the updated code from upstream.

Adding more overloads could prove to be more maintenance than it's worth.

I'm thinking of a few cases focusing on drawing text which obviously would be nicer as you want to build strings using D instead of TextFormat.

So the type of approach I would take is -- propose an overload (or set of overloads), if it makes a lot of sense that people would want to use D to construct it, and using it in a temporary fashion would not break lifetime guarantees, then we can add it. I'd even suggest a different name than the original to allow still using literals for char * calls.

I do not want to just accept a list of all functions that mechanically had char * swapped out for string. That's too much surface area to manage/test.