On Fri, 18 Jan 2019 13:47:15 -0500, Steven Schveighoffer wrote:
> I'm not speaking about rules or restrictions, I'm talking about stability. tempCString is pretty stable and likely won't change in any way except implementation details.

It's low risk but entirely unsupported. Using it in your own private code is okay; you can choose when to switch compiler versions and so forth, and if it causes any issues, you can change it right away. Using it in code intended for other people to compile is not a great idea.

On Friday, January 18, 2019 12:03:23 PM MST H. S. Teoh via Digitalmars-d wrote:
> On Fri, Jan 18, 2019 at 11:37:02AM -0700, Jonathan M Davis via Digitalmars-d wrote: [...]
>
> > The safest thing for anyone wanting to use std.internal.cstring is to just copy the module into their own project, though arguably, it's one of those things that should be cleaned up and made public instead of being in internal (which would actually break any code currently using std.internal.cstring). Regardless, I would definitely _not_ advise anyone to just import something from internal, and I definitely don't want to see anyone trying to argue later that we can't change something from internal just because a bunch of people decided that something from there was useful and started importing it. While the risk of your code breaking later on because it's using something from internal _might_ be low, it is basically begging for it to be broken at some point.
>
> [...]
>
> Shouldn't std.internal.* declare all symbols as private to std.*, like with `package` or something? Or is that not expressible currently?
>
> It's a pretty bad idea for user code to depend on std.internal.*...

It should be possible to make it package(std), and really, it should be, but it probably predates being able to do that, since that's a recent-ish feature. It's also something that I think folks tend to forget about (I certainly do), because it doesn't get used often.

- Jonathan M Davis

On Fri, Jan 18, 2019 at 07:08:02PM +0000, Neia Neutuladh via Digitalmars-d wrote:
> On Fri, 18 Jan 2019 13:47:15 -0500, Steven Schveighoffer wrote:
> > I'm not speaking about rules or restrictions, I'm talking about stability. tempCString is pretty stable and likely won't change in any way except implementation details.
> 
> It's low risk but entirely unsupported. Using it in your own private code is okay; you can choose when to switch compiler versions and so forth, and if it causes any issues, you can change it right away. Using it in code intended for other people to compile is not a great idea.

The best solution is just copy the code into your own module and use that.  In this day and age there's a stigma against copy-pasted code, but sometimes, that's exactly what the situation calls for.


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill