Concurrency adjustments, SPM: platforms, Demo: use LOCAL Package #7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Several improvements to the SDK and minor adjustments to the demo app.
platformsSPM settingsUse
platformssettings in Package.swift - this allows us to drop#availablechecks in code. Rationale: it is better to fail at compile time for developers using the Package instead of failing at runtime for users.Use local SPM package in Demo app instead of remote.
I've change so that the Demo app now uses the local Package instead of a remote. This is the intended usage (or should be!), allowing us to test our unmerged changes. This requires the
DfnsDemo/Package.swifttrick.(Pre)Concurrency fixes
The codebase is not at all prepared for strict concurrency checking / Swift Language Version: 6. So I've fixed the low hanging fruit:
DfnsApinamespace asSendable@Sendableand all inSources/DfnsSdk/Imported/Passkey.swiftDfnsSdkwith@preconcurrencyto silence some concurrency warningsStrict Concurrency Checkingis set toMinimalfor all targets (project level)Swift Language Versionis set to5for all targets (project level)Swift best practices
"Closed" the namespace enum
DfnsApidirectly (enum DfnsApi {}) making it clear it is just a namespace enum You should consider removing it, you can already doDfnsSdk.AtypeInThePackagewhen consumed in e.g. Demo app. These kind of namespaces are common on feature level, but not really needed on package level. Furthermore, if any symbols do conflict there are other ways to disambiguate, e.g. if conflicting with SwiftFoundationtypes one can do e.g.Foundation.Dataand ultimately SE-0491 will allow for full disambiguation,In Swift it is best practice to put the initialiser below the stored properties of a type, which I've changed to.
I've also added
// MARK: MyTypeannotations inSources/DfnsSdk/DfnsApi.swiftfor best minimap rendering (see minimap on right hand side):This also allows for usage of "jump bar" (CTRL 6) allowing us to jump to symbols within a large file