Stream: general

Topic: Second opinion on API design


Josh Triplett (Feb 03 2020 at 06:33, on Zulip):

I'm designing the API for a library. The library has the concept of a "tag", which the caller can provide, and which the library will give back to the caller later. The tag has to work as a filename on the filesystem, and the library receives it back from the system later as a filename and can use that to pass it back to the caller.

Should I:
1) Accept tags as AsRef<OsStr>, and return them to the caller as OsString.
Advantages: no conversion, no checks, just return what I get from the OS.
Disadvantages: Pattern matching on an OsString feels painful.
2) Accept tags as &str, return them to the caller as String.
Advantages: Easy pattern matching and indexing.
Disadvantage: Conversion (.to_string_lossy()) every time it comes back from the OS.

Josh Triplett (Feb 03 2020 at 06:57, on Zulip):

...hrm, I forgot that you also can't pattern match Option<String> using Option<&str>, which makes the use of String not really any less painful.

dubi steinkek (Feb 03 2020 at 07:45, on Zulip):

match opt.as_deref() {} should work

Josh Triplett (Feb 03 2020 at 07:53, on Zulip):

Unfortunately what I have is a struct containing two fields, one of which is Option<String> (or Option<OsString>).

Josh Triplett (Feb 03 2020 at 07:54, on Zulip):

So as_deref() by itself doesn't help.

Lokathor (Feb 03 2020 at 10:04, on Zulip):

for pathing, you have to stick to OsString or it will block some non-utf8 windows file paths from being used. of course, maybe that's not critical for this application i guess.

Josh Triplett (Feb 03 2020 at 16:27, on Zulip):

@Lokathor This library doesn't have to deal with arbitrary file paths, only paths it produced in the first place. Also, this library can't run on Windows, for unrelated reasons. (It uses UNIX sockets.)

Lokathor (Feb 03 2020 at 16:30, on Zulip):

Then simply String / str should be sufficient.

Still, you'll have to give up on matching all of it at once i guess

Last update: Jun 07 2020 at 10:25UTC