guillermomuntaner/burritos

A collection of Swift Property Wrappers (formerly "Property Delegates")

burritos's Issues

@Lazy* property wrappers are not thread safe

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.

Carthage support

Hello.
Thank you for Burritos.
As I can see Burritos does not support Carthage. I think it will be good to add this feature.

Lazy property wrapper doesn't work with closures

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

Xcode 11.4.1 (macOS) - Package resolution failed

Unable to add Burrito package to project in Xcode 11.4.1?

Rename Expirable as Cached

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.

@Lazy does not work with self

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?

The deploy target version is too high in the podspec

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?

Could it be possible using a property wrapper with Decodable and optional value?

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

No such module 'Burritos' when installing via SPM

Version 11.2.1 (11B53)
Device: iPhone 11 and iPhone Pro Max Simulator
Version: 0.0.3

//
//  ContentView.swift

import Burritos // No such module 'Burritos'
import SwiftUI

struct ContentView: View {
    @LateInit test: String
    var body: some View {
        Text("Hello, World!")
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

The module does not load and I cannot use any of the features.

Looking for ideas!

Hello everyone!

In order to extend the collection I am looking for new fresh ideas.

Thanks.

"Float80 is not available on target platform" when building for macOS on Apple Silicon

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.

Getting compile error when using @LazyConstant

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.

AtomicWrite Collections

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?