refactor the Swift Settings in Package.swift

[sebsto]

• Use the new Swift 6 @available macro to remove requirement on .platform in Package.swift.
• DRY: define the swift settings once for all in Package.swift

Motivation:

• Remove the requirement to build on macOS 15 in Package.swift. This allows library builders and end users to be more flexible on their dependency requirements.
• The code is optionally compiled on macOS 15 and Linux, but SPM don't enforce it anymore.
• Avoid repeating ourself. Be sure the same settings are applied on all targets.

Modifications:

• Create a var swiftSetting: [SwiftSettings] and reuse it for all targets.
• Use AvailabilityMacro=LambdaSwift 2.0:macOS 15.0
• Add this on top of the majority struct / classes

@available(LambdaSwift 2.0, *)

Result:

There is no more SPM dependency on macOS 15

[adam-fowler]

swift language v6 is on by default if you select a 6.0 or later toolchain, so this isn't needed

[adam-fowler]

It might be worthwhile keeping this to enable some of the other optional features like ExistentialAny, MemberImportVisibility.

[sebsto]

I started working on this because Fabian suggested to use

.enableExperimentalFeature(
            "AvailabilityMacro=LambdaSwift 2.0:macOS 15.0"
        )

on Swift 6.1

I will probably expand this PR scope

[sebsto]

@adam-fowler Do you think it's OK to use the new @availability macro in 6.1 and keep the old .platform[.macOS(.v15)] in 6.0 ?

Package-6.0.swift :

    platforms: [.macOS(.v15)],

Package.swift

        .enableExperimentalFeature(
            "AvailabilityMacro=LambdaSwift 2.0:macOS 15.0"
        )

And in the code,

#if swift(>=6.1)
@available(LambdaSwift 2.0, *)
#endif

[sebsto]

@adam-fowler

swift language v6 is on by default if you select a 6.0 or later toolchain, so this isn't needed

This was inspired from Valkey and gRPC projects.

[adam-fowler]

@adam-fowler

swift language v6 is on by default if you select a 6.0 or later toolchain, so this isn't needed

This was inspired from Valkey and gRPC projects.

haha yeah I guess so. Leave it, remove it doesn't really matter. Maybe I missed something.
I think you can leave the platform requirement in. It's not like a project will include the swift-aws-lambda-runtime package and not use it. It is more likely to happen for client libraries (like valkey) where the library might be set to be available based on the existence of a trait.

[sebsto]

@adam-fowler Fabian has a good point about the availability macro

Lambda requires macOS 15. Hummingbird wants to support Lambda out of the box via a package trait. But currently Hummingbird only requires macOS 13. This will not work, as Lambda has a higher deployment target. Hummingbird in this case has to increase their deployment target to macOS 15, if they want to support lambda out of the box. Or create a hummingbird-lambda package (uncool).
What you want is that Lambda can only be run on macOS 15 or higher, but that Hummingbird can still be deployed to macOS 13.

Would that help to remove the platform requirement for HB ?
And if I do, would it be usefull if applied to Swift versions >= 6.1 only ? (not Swift 6.0)

[adam-fowler]

Would that help to remove the platform requirement for HB ?
~~

Doesn't really affect HB. The only time we include this package as a dependency is when we need to use it, so the platform requirement is valid.