std.algorithm: set accidentally exposed methods to private

[wilzbach]

follow-up to #4312. This includes a couple of accidentally exposed publicly exposed methods - they weren't documented.
For permutations I added deprecations, but I would prefer if we can live without them ;-)

[burner]

this must be a property

update:
pure nogc nothrow safe

[burner]

I think the renames from ID to _ID are useless. That is what "this." is for.

[burner]

IMO the schedule for removal is to short. Has this been discussed somewhere?

[JackStouffer]

@wilzbach typically, deprecations are between a year and two years

[wilzbach]

AFAIK Permutations is a very recent addition and the internals of permutations where never publicly documented, that's why I thought just six months would be okay. Imho no deprecation should also be okay, because I can't imagine someone digging through the phobos source code and using the state variable.

[Geod24]

AFAIK Permutations is a very recent addition and the internals of permutations where never publicly documented, that's why I thought just six months would be okay. Imho no deprecation should also be okay, because I can't imagine someone digging through the phobos source code and using the state variable.

Almost one year old. If it hadn't part of a release already it would have been okay, however everything that was (even once) should follow the proper deprecation path.

I cannot imagine someone digging through the source code and accessing Dalvik's internal and modifying the system loader, yet it's done on most of the phones out there.

[burner]

but you don't know what people do.That is the point here. Just because you wouldn't, does not mean somebody else wouldn't.

[wilzbach]

I think the renames from ID to _ID are useless. That is what "this." is for.

Yes absolutely, but needed for the deprecation - otherwise you would have conflicting names.

I cannot imagine someone digging through the source code and accessing Dalvik's internal and modifying the system loader, yet it's done on most of the phones out there.

Updated to June 2017 - is this ok?
(and addresses @burner's comment about the properties)

[dnadlinger]

Doesn't this break l-value access to the fields in its current form?

[wilzbach]

Doesn't this break l-value access to the fields in its current form?

Yes it did. I still think that someone should be punished if he fiddles with that, but it now triggers proper deprecation warnings ;-)

[JackStouffer]

LGTM