Closes #592 -- allows for incomplete specification of new order in setcolorder - #1792

@MichaelChirico can't just neworder move those columns to front in provided order, then all others. No new args, and no breaking changes as we put new feature in place of error Error in setcolorder(dt, "b") : neworder is length 1 but x has 2 columns..

@jangorecki that seems reasonable. Approach in this PR represents a more general new feature, but as you point out, may be tougher to merge into current paradigm. If people actually ask for that, may be worth revisiting. Given that issue has little apparent traffic, your suggestion probably covers vast majority of empirical use cases.

Will edit this PR and resubmit.

Current coverage is 90.21% (diff: 100%)

Merging #1792 into master will increase coverage by 0.02%

@@             master      #1792   diff @@
==========================================
  Files            58         58          
  Lines         11141      11147     +6   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits          10048      10056     +8   
+ Misses         1093       1091     -2   
  Partials          0          0          

Powered by Codecov. Last update 6706882...32aab12

@mattdowle why not just new argument then? we used to not create new functions for new stuff if it is not really needed, setcolorder is still good name for function to reorder partially.

Maybe new argument. Looking more into it, what happened to my original request of not just moving to the beginning but moving a column to a particular position? The title of #592 (that I filed on R-Forge in 2013, so I remember wanting the ability for some reason at the time) is "Add new movecol(DT, "colname", 1) ". This PR doesn't close that request because it always moves to the beginning.
Perhaps setcolfirst() is too restrictive, maybe setcolpos() then?

setcolpos(DT, "b", 1)   # move b first
setcolpos(DT, c("b", "d"), 1)  # move b and d first
setcolpos(DT, c("b","d"), 10)  # move b and d to be positions 10 and 11.
setcolpos(DT, c("b","d"), before="someCol")   # move b and d to be just before someCol.

That was how I originally programmed it, as a new argument to setcolorder (so it works like setnames). I unfortunately just overwrote that to make jan's adjustment.

Problem with that PR was that I used new argument names which made more sense for the more robust version of setcolorder, but which would have broken old code.

I see now - yes comparison to setnames is helpful. What would have broken? setnames checks missing(new) first and then takes old as if it were new. Perhaps it could be done in the same way for setcolorder so that nothing breaks.

Given the analogy/parallel use, perhaps we should change the setcolorder arg names to old and new?

Again this gets at the breaking change issue. But perhaps we can continue to accept neworder with warning?

(as it stands, the current argument is already neworder when we'd like it to be renamed oldorder or old, is basically the issue)

Sounds reasonable to me. So it would be setcolorder(DT,old,new,neworder)? If user code contains setcolorder(DT,neworder=o), the warning would ask to either change to new= or no named argument at all. Then in future, remove neworder=. Any existing code such as setcolorder(DT, o) where o is passed unnamed, will continue to work in future and need to be as long as ncol(DT) just like setnames(DT, newnames).
In fact, the new argument could just be called neworder= and then no warning would need to happen. But then we'd be stuck with the old name and inconsistency with setnames. So I'd lean towards named neworder= being a warning and then deprecate it, yes. Think it's quite low risk that users have named that argument and would mind changing.
Jan?

Actually Jan said it broke some of his own code to have different argument names! Since he called neworder specifically.

I do like the consistency with setnames, I think that's why I found this issue in the first place, was trying to use setcolorder like I do setnames.

Sorry, I missed that part of PR.
Change of neworder argument breaks (at least) two of my pkgs. Better to avoid argument name changing if it isn't really necessary.
setcolorder(DT,old,new,neworder) is good one

Merging as-is. Thought process ...
Looking back with fresh eyes, I was being over-cautious on this one: the convenience of the common case of moving columns to the front outweighs the loss of the (most often, inconvenient, rather than welcomed) error. This PR itself doesn't add any functions or arguments and so won't impact any dependent packages. It's a good low-risk first step. Whether and how to move a subset of columns to a not-first position can be revisited in future. I can't see that accepting this PR now will rule out any options in future.