Can std.conv.toImpl please be deprecated

[H. S. Teoh via Digitalmars-d]

On Sun, Apr 17, 2016 at 03:32:16AM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Saturday, April 16, 2016 22:04:46 H. S. Teoh via Digitalmars-d wrote:
> > On Fri, Apr 15, 2016 at 05:23:26PM +0000, Jack Stouffer via Digitalmars-d 
> wrote:
> > > Before I opened a PR, I wanted to get some second opinions.
> > >
> > > There is no reason IMO that the various overloads of toImpl should
> > > be public. Having the internal functionality of a parent function,
> > > in this case to, be exposed like this causes:
> > >
> > > 1. The docs to be cluttered with useless info. Anything pertinent
> > > can be moved to the to docs.
> > > 2. The function cannot be refactored because its guts are shown to
> > > the world
> > >
> > > Also, there is no reason that anyone should use toImpl over to. So
> > > can I please mark toImpl as deprecated in order to clean up
> > > std.conv?
> >
> > I'm pretty sure that toImpl being public is an oversight. The name
> > itself implies that it should be private.  I seriously doubt any
> > user code actually calls toImpl directly... shouldn't it be just a
> > matter of marking it private instead?  Do we really need to go
> > through a deprecation cycle for this?
> 
> toImpl has the documentation for all of the specific conversions. So,
> you can't make it private or that documentation would go away.
[...]

Easy, just move that documentation to the docs for `to`.

It's probably better that way anyway, as exemplified by this very thread
where somebody already expressed confusion over using toImpl with a
conversion base vs. using to with a conversion base, where the latter is
probably the original intended usage.


T

-- 
I think the conspiracy theorists are out to get us...