> Even on Linux, you can't have '/' in a filename, or ':' on macOS

Yes this is why all competent libraries don't actually use string for path. They have their own path data type because it's actually a different data type.

Again, you can do the Go thing and just use the broken string, but that's dumb and you shouldn't. They should look at C++ std::filesystem, it's actually quite good in this regard.

> And a language that doesn't provide the tooling necessary to muddle through this mess safely isn't a serious platform to build on, IMHO.

I agree, even PHP does a better job at this than Go, which is really saying something.

> Go is making the tradeoff for language simplicity, while being marketed and positioned as a serious language for writing serious programs, which it is not.

I would agree.

▲

astrange 3 days ago | parent [-]

> Yes this is why all competent libraries don't actually use string for path. They have their own path data type because it's actually a different data type.

What is different about it? I don't see any constraints here relevant to having a different type. Note that this thread has already confused the issue, because they said filename and you said path. A path can contain /, it just happens to mean something.

If you want a better abstraction to locations of files on disk, then you shouldn't use paths at all, since they break if the file gets moved.

▲

const_cast 3 days ago | parent [-]

A string can contain characters a path cannot, depending on the operating system. So only some strings are valid paths.

Typically the way you do this is you have the constructor for path do the validation or you use a static path::fromString() function.

Also paths breaking when a file is moved is correct behavior sometimes. For example something like openFile() or moveFile() requires paths. Also path can be relative location.

▲

astrange 3 days ago | parent [-]

> A string can contain characters a path cannot, depending on the operating system. So only some strings are valid paths.

Can it? If you want to open a file with invalid UTF8 in the name, then the path has to contain that.

And a path can contain the path separator - it's the filename that can't contain it.

> For example something like openFile() or moveFile() requires paths.

macOS has something called bookmark URLs that can contain things like inode numbers or addresses of network mounts. Apps use it to remember how to find recently opened files even if you've reorganized your disk or the mount has dropped off.

IIRC it does resolve to a path so it can use open() eventually, but you could imagine an alternative. Well, security issues aside.

	▲	adastra22 3 days ago \| parent [-]
		Rust allows null bytes in str. Most (all?) OS don't allow null bytes in filenames.