std.algorithm cleanup

[quickfur]

• Move forward to std.functional
• Move SortOutput to std.algorithm.sorting
• Cleanup rest of detritus in std/algorithm/package.d.

[andralex]

Thanks! Was forward available from std.algorithm before this change? If so, you may want to insert a public import in order to not break code.

[andralex]

Was forward available from std.algorithm before this change?

Meant to say: was it available in 2.066?

[quickfur]

Hmm, git history indicates that it was added in 2012, so we definitely need to forward it to the new location. I'm uneasy about using a public import, though... wouldn't that pollute std.algorithm with std.functional symbols? It might also cause new conflicts. Is there a way to publicly import a specific symbol?

[quickfur]

Also, should there be a deprecation message to point users to the new location of forward?

[schveiguy]

wouldn't that pollute std.algorithm with std.functional symbols?

It appears that it already is that way, as your change removes that import. Can you statically import it, and than alias the symbol?

Is there a way to publicly import a specific symbol?

I think you can simply import the symbol you want directly, no?

should there be a deprecation message to point users to the new location of forward

Yes, so probably the right way to do this is to use a deprecated alias.

[quickfur]

I used a private import. Is a static import better? What side effects might it have? I remember that imports have some quirky semantics when it comes to visibility.

And for some reason, adding a deprecation clause to the alias doesn't seem to trigger a deprecation error even when compiling with -de. Is this a known bug?

[quickfur]

Alright, I'm adding it anyway, since I don't have time to babysit this all day. At least when the compiler is fixed the message will appear. For now it will just be a transparent alias.

[schveiguy]

used a private import. Is a static import better? What side effects might it have?

I think a static import prevents the import of std.functional's symbols into std.algorithm's namespace. Basically, you have to say std.functional.x every time.

The deprecation message should work, I tested it on a small example, exactly as you have it, and a message is printed.

[schveiguy]

Note that if you happen to have imported std.functional elsewhere (not via std.algorithm), you will not hit the alias.

[quickfur]

Maybe my compiler is broken, I'll try to recompile git HEAD and see if the message appears. In the meantime, I've changed it to a static import with a deprecation message. Should be ready to merge if there are no other issues. The deprecation message issue, if it's actually a real issue, can be done separately, no need to hold up this PR just because of that.

[kuettler]

I guess, it is the import std.functional; in e.g. comparison.d, which is publicly imported in package.d, that might be in the way of the deprecation message.

[kuettler]

Seems good to me.

[andralex]

Auto-merge toggled on

[schveiguy]

that might be in the way of the deprecation message.

yes, that's likely it. In reality, this means the alias will not be hit, since importing std.algorithm means you will import std.algorithm.comparison. However, in the event that private imports actually do become private, then the alias will be effective.