Error can be handled with the inner-type pattern, where
pal_common defines a common
Error type with less features than the one in
I'm not sure, but I suspect there are semantic differences that would be exposed.
This would be a reasonable approach.
It's hard to guess whether that is sufficient.
io::Error is used for many purposes in std that are not associated with those traits.
It depends on what you mean by platform-specific. The example here showed that it is platform-specific in that the implementation uses platform-specific features.
Those features are just optimizations of convenience though because libc happens to have efficient implementations of memchr (and one other function I can't recall off-hand). There is nothing about the definition of C strings that is tied to an operating system (though the definition of c_char is ABI-specific, c_char is one of the few C types std defines), so one could implement them without calling into libc, and in that sense CStrings are platform-independent.
I'd be interested to know your motivation for not having CString (I inderstand not wanting to link to libc). If it's just because you don't need it that's fine.
There are various ways one could imagine not implementing and/or exposing CStrings. Scenarios are one.
(Looks like CStrings have been well discussed in this thread so I won't comment further).
panic! is the simple answer. I'm not sure if there's any particularly better strategy, except where there are useful defaults. One must either stub out functionality or implement everything at once.
I mentioned this in passing as potential future work. Any appropriate division here will become more clear as the work progresses.