Bug 211270

Created attachment 398136 [details] Patch

Comment on attachment 398136 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=398136&action=review > Source/WebKit/ChangeLog:3 > + Create Swift overlay for WebKit framework This change log says a lot, but it doesn’t way why we are doing this!

Comment on attachment 398136 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=398136&action=review >> Source/WebKit/ChangeLog:3 >> + Create Swift overlay for WebKit framework > > This change log says a lot, but it doesn’t way why we are doing this! Such as why do a Swift overlay at all? I thought I explained that with my explanation of individual changes, but to step back this is about providing APIs that use Swift-native idioms that cannot be expressed in Objective-C. For example, Swift can have optional scalar types like Optional<CGRect>, where in Objective-C a similar concept is CGRectNull. The former provides compile-type type correctness while the latter is just a magic value. Result<T, Error> is the async equivalent of a throwing function, and enforces mutual exclusion for functions that return either a value or an error. Without it, using the direct Objective-C import of (T?, Error?) you end up with four possible states, two of which are invalid (ex: (nil, nil) and (T(), Error())). Without getting in to future plans, we could do a lot more with this too. I'm really proposing some light polish with these changes.

Committed r262089: <https://trac.webkit.org/changeset/262089> All reviewed patches have been landed. Closing bug and clearing flags on attachment 398136 [details].