string from C function - to!string

[Jonathan M Davis]

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