The deployment target seems too high:

  s.ios.deployment_target = '13.0'
  s.osx.deployment_target = '10.15'
  s.tvos.deployment_target = '13.0'
  s.watchos.deployment_target = '6.0'

The wrapper is a compiler feature, not the runtime. Is it right?

This creates a color that will auto-update on iOS 13, and falls back to the light color on any version less.

I'm very unsure about my approach with the tests - what's best practice for testing different iOS versions behavior? Open to suggestions.

First of all, amazing collection of Property Wrappers you have here!! Truly a great resource! So thank you!! 🎉

One thing I noticed, is the AtomicWrite property wrapper doesn't handle collections the best. I could be thinking about this wrong, but when accessing the underlying properties or functions, it doesn't do it in an Atomic way as far as I can tell. Since collections are just pointers to other items in memory, accessing those other items is not handled in an atomic way.

What are your thoughts on this? Do you think there is potential for maybe an extension on top of AtomicWrite that would help access the items in a collection in an Atomic way?

Use os_unfair_lock if it is available, otherwise fall back to pthread_mutex.

This should give a nice performance boost according to the tests in this article: https://www.cocoawithlove.com/blog/2016/06/02/threads-and-mutexes.html

Wouldn't it be intuitive to have @Expirable as @Cached instead? Coz token usually isn't expired(if we're talking from the app's point of view) i.e. the server manages token's life time and client simply caches it for limited time.

Hi @guillermomuntaner , thanks your great repo, It's very helpful for swift developing.

It' seems that you have learn a lot about using property wrapper to provide convenient feature. Could you do me a favor, for helping me resolve the problem, just like what title says.

The situation is that, when using Decodable We need to know every property that is optional or not to define the model That's too hard to ensure you get what you want Sometime server just update, you fail to parse the data

But like other framework as HandyJSON, they provide default value for model We can safely define every property as non-optional with that

Is there a way to achieve this with Property Wrapper for Decodable? Thanks in advance

I used Swift 5.1/Xcode 11.1 to reproduce this issue. Consider the following code:

protocol P {
    func f()
}

struct S: P {
    func f() { }
}

func f(p: P) {
    p.f()
}

class C {
    @LazyConstant
    var s: S = {
        return S()
    }()

    func g() {
        f(p: s)
    }
}

Getting the following error: Expression type '()' is ambiguous without more context. To fix it replace f(p: s) with f(p: s as P). But as for me this is a bug. I also created an issue at https://bugs.swift.org.

Hello. Thank you for Burritos. In this pull request I added MappingSetter. I was inspired by Trimmed, however MappingSetter is more flexible, you can set any mapping function.

One of the main reasons I use lazy is when I need access to self, lazy allows me to defer creation of the property to access-time (i.e. when self is available).

Is there a way to make @Lazy support self?

I get this error building for macOS on Apple Silicon using 12.5 beta 3 (12E5244e):

'Float80' is unavailable: Float80 is not available on target platform.

I suspect that has something to do with Apple Silicon so the check should be different based on architecture.

Simple playground test:

class Test {
    lazy var myLazyVar: Void = {
        print("crazy")
    }()
}

print("Initialize: ")
var test = Test()
print("call first")
test.myLazyVar

will print:

Initialize: 
call first
crazy

but then you have:

class Test {
    @Lazy var myLazyVar: Void = {
        print("crazy")
    }()
}

print("Initialize: ")
var test = Test()
print("call first")
test.myLazyVar

which will print:

Initialize: 
call first

Bumped minimum iOS deployment version from 8 to 9 in order to comply with Xcode 12's minimum deployment range. Fixes compiler warning when installing via SPM.

The @Lazy and @LazyConstant property wrappers do not appear to be thread safe. That is, if two threads attempt to hit the initial getter at the exact same time, they will both attempt to initialize the value. Running the initializer multiple times can have the adverse effect of executing the "expensive operation" multiple times, which is not a good thing.

Note: This only would happen if the @Lazy objects are accessed in multiple threads. For UIKit initializers, everything must be done on the main (synchronous) thread, and so we don't have this issue.

The "standard" solution for such a case is creating a concurrent queue, and doing the work within the getter in a queue.sync{} block, and (for the non-constant @Lazy implementation), putting the setter into an async{} .barrier to ensure the reads and writes are synchronized. This would require that a DispatchQueue be created for every @Lazy property, but this has the side-effect of possibly creating many, many GCD queues, which isn't needed for the UIKit exception I mentioned above. This might require maintaining a pool of thread objects, assigned to each @Lazy object, but we're now adding even more complexity to what should be a simple property wrapper.

So, my suggestion is to provide two additional property wrappers to have a total of four @Lazy style objects:

1. @Lazy -- Current modifiable implementation
2. @LazyConstant -- Current constant implementation
3. @LazyQueue -- @Lazy + barrier queues
4. @LazyQueueConstant -- @LazyConstant + synchronous queues

An even better implementation would allow the passing of an OptionSet to supply [.constant, .queue] to the initializer, but that makes the @Lazy(flags: [], wrappedValue: { ... } var foo quite complex to write.