Disambiguate symlink argument names

[dtolnay]

The current argument naming in the following standard library functions is horribly ambiguous.

• std::os::unix::fs::symlink: https://doc.rust-lang.org/1.47.0/std/os/unix/fs/fn.symlink.html
• std::os::windows::fs::symlink_file: https://doc.rust-lang.org/1.47.0/std/os/windows/fs/fn.symlink_file.html
• std::os::windows::fs::symlink_dir: https://doc.rust-lang.org/1.47.0/std/os/windows/fs/fn.symlink_dir.html

Notice that Swift uses one of the same names we do (dst) to refer to the opposite thing.

	the one that exists	the one that is being created	reference
Rust	src	dst
Swift	withDestinationPath destPath	atPath path	https://developer.apple.com/documentation/foundation/filemanager/1411007-createsymboliclink
D	original	link	https://dlang.org/library/std/file/symlink.html
Go	oldname	newname	https://golang.org/pkg/os/#Symlink
C++	target	link	https://en.cppreference.com/w/cpp/filesystem/create_symlink
POSIX	path1	path2	https://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html
Linux	target	linkpath	https://man7.org/linux/man-pages/man2/symlink.2.html

Out of these I happen to like D's argument names and am proposing that we adopt them.

[rust-highfive]

r? @sfackler

(rust_highfive has picked a reviewer for you, use r? to override)

[jyn514]

Personally I prefer target over original ('the target of the symbolic link'), especially since original may not exist on disk. +1 to improving this one way or another, though.

[dtolnay]

"Target" is close to synonymous with "destination" and almost as bad IMO.

[Mark-Simulacrum]

r=me implementation wise

I do think that original is better than target (target for what?). I sort of want to do "more" here (e.g. force callers to explicitly name their arguments) but I don't think we can readily do so today and this seems like an improvement already. Feel free to r=me unless you want to let this sit for libs feedback (or just general discussion). It seems low cost to rename these multiple times though if necessary.

[ehuss]

👍 to making it clearer. Out of curiosity, I collected a few other naming conventions:

	the one that exists	the one that is being created	reference
Java	target	link	https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/nio/file/Files.html#createSymbolicLink(java.nio.file.Path,java.nio.file.Path,java.nio.file.attribute.FileAttribute...)
Python	src	dst	https://docs.python.org/3/library/os.html#os.symlink
Ruby	old_name	new_name	https://ruby-doc.org/core-2.5.0/File.html#method-c-symlink
Node.js	target	path	https://nodejs.org/api/fs.html#fs_fs_symlink_target_path_type_callback
Windows	lpTargetFileName	lpSymlinkFileName	https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createsymboliclinka

[mati865]

Notice that Swift uses one of the same names we do (dst) to refer to the opposite thing.

IMO their names are even worse but it's subjective.

Both original and src for the first argument seem pretty clear but for the second argument link would be big improvement.
You could ask the community to think of the new names, maybe somebody comes up with even better ones.

[the8472]

ln uses target and link_name

https://man7.org/linux/man-pages/man1/ln.1.html

[dtolnay]

@bors r=Mark-Simulacrum

[bors]

📌 Commit 29128a5 has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 29128a5 with merge 09c9c9f...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 09c9c9f to master...