Bug 211270 – WebKit Swift Overlay

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit API

[James Savage]

Create Swift overlay for WebKit framework.
<rdar://problem/60549174>

[James Savage]

Created attachment 398136 [details]
Patch

[Darin Adler]

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!

[James Savage]

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.

[EWS]

Committed r262089: <https://trac.webkit.org/changeset/262089>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 398136 [details].