[webview_flutter_wkwebview] Remove specialization of 'map' to fix Swift warning

[jmagman]

Seen when upgrading to Xcode 26.

Introduced in #8311.

Fixes flutter/flutter#173744

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

[gemini-code-assist]

Code Review

This pull request correctly removes an explicit type specialization in a Swift map call to resolve a compiler warning. I've added a couple of suggestions. One is to correct the CHANGELOG entry, as the change affects the plugin's source code, not the example app. The other, more critical suggestion is to replace try! with try on the modified line to prevent a potential runtime crash and properly propagate errors, aligning with the function's throwing signature.

[gemini-code-assist]

Using try! can cause a crash if the map operation throws an error. The closure can throw an error, for example, for an unknown enum case or when sameSitePolicy is used on an older OS version. Since the pigeonDefaultConstructor function is marked with throws, the error should be propagated with try instead of try! to prevent a potential crash.

Suggested change

	let keyValueTuples = try! properties.map {
	let keyValueTuples = try properties.map {

[jmagman]

I'm not a Swift expert, @hellohuanlin what's the idiomatic thing to do here? And is that correct in the context of this plugin?
There are no warnings without the !

[hellohuanlin]

Looking at the caller:

packages/packages/webview_flutter/webview_flutter_wkwebview/darwin/webview_flutter_wkwebview/Sources/webview_flutter_wkwebview/WebKitLibrary.g.swift

Lines 1654 to 1660 in 27a2302

	do {
	api.pigeonRegistrar.instanceManager.addDartCreatedInstance(
	try api.pigeonDelegate.pigeonDefaultConstructor(pigeonApi: api, url: urlArg),
	withIdentifier: pigeonIdentifierArg)
	reply(wrapResult(nil))
	} catch {
	reply(wrapError(error))

It wraps pigeonDefaultConstructor call under a do/catch block, and if it throws, it replies error to the dart side.

So if you use try here, when it throws, it will be eventually propagated to dart side;
If you use try! here, when it throws, it will crash.

Given that this code is setup this way (throwable method + do/try/catch block), I'd say the expected usage is not to crash. So let's go with try.

[jmagman]

Done!

[jmagman]

It was complaining because line 13 above in the function declaration already contains the type information [HttpCookiePropertyKey: Any]

[hellohuanlin]

Interesting! The old rule is that yon can always explicitly provide types, and what's more, sometimes you must explicitly provide types for super long statements where swift compiler fails auto-infer the types).