[Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""

[Martin Maechler]

>>>>> Hervé Pagès 
>>>>>     on Tue, 26 May 2020 12:38:13 -0700 writes:

    > Hi Martin, On 5/26/20 06:24, Martin Maechler wrote: ...
    >> 
    >> What about remaining back-compatible, not only to R 3.y.z
    >> with default recycle0=FALSE, but also to R 4.0.0 with
    >> recycle0=TRUE

    > What back-compatibility with R 4.0.0 are we talking about?
    > The 'recycle0' arg was added **after** the R 4.0.0 release
    > and has never been part of an official release yet. 

Yes, of course.  It was *planned* for R 4.0.0 and finally was
too late (feature freeze etc)... I'm sorry I was wrong and
misleading above.

    > This is the time to fix it.

Well, R 4.0.1 is already in 'beta' and does contain it too.
So the "fix" should happen really really fast, or we (R core)
take it out from there entirely.

    >> *and* add a new option for the Suharto-Bill-Hervé-Gabe
    >> behavior, e.g., recycle0="sep.only" or just
    >> recycle0="sep" ?

    > OMG!

    >> As (for back-compatibility reasons) you have to specify
    >> 'recycle0 = ..'  anyway, you would get what makes most
    >> sense to you by using such a third option.
    >> 
    >> ? (WDYT ?)

    > Don't bother. I'd rather use

    >    paste(paste(x, y, z, sep="#", recycle0=TRUE), collapse=",")

    > i.e. explicitly break down the 2 operations (sep and
    > collapse). Might be slightly less efficient but I find it
    > way more readable than

    >    paste(x, y, z, sep="#", collapse=",", recycle0="sep.only")

    > BTW I appreciate you trying to accomodate everybody's
    > taste. That doesn't sound like an easy task ;-)


    > I'll just reiterate my earlier comment that controlling
    > the collapse operation via an argument named 'recycle0'
    > doesn't make sense (collapse involves NO recycling). So I
    > don't know if the current 'recyle0=TRUE' behavior is "the
    > correct one" but at the very least the name of the
    > argument is a misnomer and misleading.

    > More generally speaking using the same argument to control
    > 2 distinct operations is not good API design. A better
    > design is to use 2 arguments. Then the 2 arguments can
    > generally be made orthogonal (like in this case) i.e. all
    > possible combinations are valid (4 combinations in this case).

I don't disagree about the principle...