On Wednesday, May 14, 2025 5:38:59 AM Mountain Daylight Time Nick Treleaven via Digitalmars-d-learn wrote: > On Wednesday, 14 May 2025 at 03:36:40 UTC, Jonathan M Davis wrote: > > to!string definitely deals with null-terminated strings, or it > > wouldn't work at all. It's not the kind of thing that would > > work by accident. > > I don't think it's good API design: > > > Pointer to string conversions convert the pointer to a size_t > > value. If pointer is char*, treat it as C-style strings. In > > that case, this function is @system. > > So `to!string` is bad for generic code. Want to represent the > address of a byte* as hex in a string, fine. Oh now the pointer's > element type is char - wait, why isn't the result hex any more? > > I really dislike overloads having different behaviour like this > and it would be nice if Phobos 3 could take a much stricter > stance on that. > > On the docs: > > This special behaviour is buried as *part* of a single bullet > point in long documentation that is not easy to find. (And > there's currently no anchor link for that section - each > 'Examples:' section should probably have one).
There is certainly an argument that treating char* differently from other pointer types is bad design due to it being inconsistent, but it's also true that how any particular conversion works exactly is going to depend on the types involved. And to an extent, relying on specific conversion behaviors in generic code is going to be error-prone regardless, because at the end of the day, the conversions aren't generic. There are always going to be inconsistencies of some kind. It's just a question of which ones are ultimately more beneficial. There's also an argument to be had that if you want specific conversion behavior for pointers, you should be casting to void*, because then you're no longer dealing with a generic conversion (and it reduces the number of template instantiations to boot). In any case, I'm certainly not going to say what we're going to do with Phobos v3 and std.conv.to with regards to null-terminated strings at this point, since we're not that far along. It will need to be examined when it's ported / reimplemented for Phobos v3, and we'll make decisions then. You make a good point, but there are also good arguments that the current behavior is more user-friendly. So, we'll see. Either way, there's no question that std.conv.to will need to be examined in detail when creating the Phobos v3 version, and we'll be trying to make it cleaner and simpler than what's currently there, since what's currently there is a bit of a maze of templates. However, pretty much the only clear decision at this point is that the new code (whether it's a port of the current code or fully new code) will have at least two variants - one which is just like to and throws on failure (and which will probably still be called to) and another which returns the value wrapped in Phobos v3's optional type rather than throwing an exception (and that overload will probably be called tryTo). That way there will be a conversion function that can be used in code where it's reasonable to assume that the conversion succeeds while the code that can't reasonably make that assumption doesn't have to choose between catching an exception and validating the input to avoid an exception just to have it validated again by the conversion function. - Jonathan M Davis
