Deno: Reverse the current signature of `Deno.copy`

[tunnckoCore]

As seen here https://twitter.com/tunnckoCore/status/1200346772893323264

Currently copy signature is dst, src which totally deviates from the standard one which is used in the rest of the API - copyFile, readFile, writeFile are all src, dest.

And more or less the API is already following the years of experience in Node.js and is more or less similar thing. There's no copy in Nodejs and that's the only thing that is different in Deno. For me, it doesn't make sense to randomly follow some other language signature and more so one single method of a whole API.

[kevinkassimo]

Hmm I wouldn't include writeFile as an example since it is also technically specifying dst (filename) before src (Uint8Array).

I am personally okay with either ordering.

I do want to point out that some actually argue the reason for Unix-y dst, src argument pair is the mindset of dst = src (assignment) <--> copy(dst, src)

For references of fixing the order, Rust did the switch and had an interesting discussion here and related discussion

[tunnckoCore]

Ah, actually, yeah - correct.

I can see why copy can and is following the underlying language API. But at least we should take the fact that's it's more intuitive and more natural to say "copy this to that", where this is src and that is dest - just like cp and mv.

Seeing such decisions not for the first time, I never understood why things like Deno (tools, languages and etc) that are based on something should partly inherit the lower-level. Even more in the case of Deno, where the ecosystem and community has nothing to do with Go or Rust - meaning that Deno is oriented to javascript/nodejs/typescript/web developers which may not be (and it's not required to be) familiar with such langs. Deno is providing familiar Web/nodejs/browser APIs. What if we have move? If we follow the current logic it will have dst, src signature too?

Hypothetically, It's like as package author (in nodejs realm) to export readFileAsync and readFile (sync) instead readFile and readFileSync just for the sake to be different and mess with consumer's minds.

[ry]

@tunnckoCore Much of Deno's internal code is ported from Go, including this copy function. The ordering of arguments is intentional - it's like strcpy in C.

[tunnckoCore]

Yea, okay. But why web developers should accept something inherited from lower-level bases and write in a way that's not aligned to some logical, natural & intuitive way? Okay, they will, and most probably won't care why it's that way, and learn it and write it that way, but...

And yea, okay, it's probably a bit religious thing. I'm in programming for a decade and I just don't getting why this is done. The logical sense and natural way of thinking while writing it is that you're copying A to B, and you're kind of supposed to write it in the same way/direction copy(src,to dest). If it's reversed it will mess up with every single human/developer, except those that are skilled and know the reasons and what's happening under the hood.

I'm always about the little things and details. They some times can drive me crazy and I'm sure I'm not the only one.

[ry]

I was overruled in this. We are changing the order of copy's args

https://github.com/denoland/deno/pull/4885

[tunnckoCore]

Awesome! <3