Pitch(Foundation): String Encoding Names

[YOCKOW]

Thank you so much for your reply!

---

@itingliu

You have this in your Alternatives Considered section, which @jmschonfeld also mentioned before, to have something like this. What's the reason that you're not pursuing this idea?

To be honest, there was no significant rationale.
I thought it was better to discuss if we had some concrete (sample) implementation, then I had chosen the one just described in the previous pitch.

@itingliu

Although I do like having all initializers laid out, and only reserve the enum NameType for getters, i.e. something like this. What do you think?

I had no idea that we could have getters-initializers asymmetry, but I think now it's the better or the best way to realize this feature. Thank you for your input.

@itingliu

While we're at it, is charsetName and standardName the standard way to refer to IANA and WHATWG standards? Would it be more straightforward to just name the arguments as

public init?(ianaName: String)
public init?(whatwgName: String)

That's certainly easy to understand.
(One possible alternative could be ianaName↔︎ianaCharsetName, whatwgName↔︎whatwgEncodingName...redundant?)

---

@itingliu

@YOCKOW

CF APIs are officially unavailable from Swift on non-Darwin platforms.

Nitpick: You can still use CF API through swift-corelibs-foundation on non-Darwin platforms. But yes, that is not Swift, and you're right that it's useful to have Swift parity.

I'm sorry but the reason why my expression was as such was in the context of the other thread. A footnote should have been added.

The Context

Swift-foundation now available

As for CoreFoundation, some functions such as CFStringConvertNSStringEncodingToEncoding and CFStringConvertEncodingToIANACharSetName that are currently available on both of Darwin and non-Darwin with import CoreFoundation are not exposed via Swift API. FoundationEssentials uses them internally, but doesn’t seem to expose them publicly. Will they keep available, or be rewritten in Swift?

Swift-foundation now available

CoreFoundation was never meant to be user visible with swift-corelibs-foundation. This is one of the big differences between Windows and Linux with swift-corelibs-foundation. Because the Windows port happened later, that was addressed and is why the CoreFoundation functions are not visible on Windows. I expect that as swift-corelibs-foundation becomes more a forwarder for swift-foundation, those APIs should shrink and disappear on Linux as well.

Swift-foundation now available

I can understand what you say, but I’d rather insist that I don’t think CoreFoundation is a mere backend of swift-corelibs-foundation de facto. For example, CFStringConvertEncodingToIANACharSetName and its complementary function CFStringConvertIANACharSetNameToEncoding (of which I gave examples above) are very useful to (and widely used by) server-side programs and web client programs. I hope equivalent APIs are worked out in swift-foundation even if CoreFoundation would become unavailable.

Swift-foundation now available

Hey @YOCKOW - you're right that function doesn't seem to have a Swift equivalent in our current APIs. For functions in CoreFoundation that are useful in the Swift ecosystem, I think the best approach (as you mentioned) is to publish them as official Swift APIs rather than continue to call to CoreFoundation to use them (that way eventually they can be removed from CoreFoundation in swift-corelibs-foundation). This one in particular seems relatively simple in implementation and is actually alread…

Swift-foundation now available

That makes sense since Foundation is now more open than ever. I'd try to write a pitch if I have enough time, or I welcome someone else writing the pitch. Thank you.