The current proposal does not have an all= argument so there is no conflict.
Suppose all.x= were later added to [.data.table. The all= argument in merge provides the default value for both all.x= and all.y= and all= itself is set to have a default of all=FALSE; however, for data.table if there were an all.x= added then it would have the default all.x=FALSE while all.i= would have the default of all.i=TRUE thus one could never have an all= argument to [.data.table that provides the default for both so I don't think this would ever be a problem. On Sat, May 4, 2013 at 8:44 AM, Karl Ove Hufthammer <[email protected]> wrote: > la. den 04. 05. 2013 klokka 07.40 (-0400) skreiv Gabor Grothendieck: >> I am not sure but I think that could be handled as a separate issue if >> it becomes important. By using all.i= it makes it sufficiently >> different from all.y= that users won't expect the same default and >> further they will not necessarily expect that there be an all argument >> for the left participant in the merge. > > But won’t ‘all’ (e.g., ’all=TRUE’) automatically match ‘all.i’, while at > the same time not give the same result as ‘all’ in ‘merge’? That could > be confusing. > > -- > Karl Ove Hufthammer > > _______________________________________________ > datatable-help mailing list > [email protected] > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com _______________________________________________ datatable-help mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
