Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

async(.promise) and promises (docs still accurate?)

Aperta
  • Qualcosa non va?
#1,018 1 commento 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
swift
Ambito
api, documentation

Direzione di ricerca

Start with the Appendix passage and reproduce the reported async(.promise) examples using the current Swift and PromiseKit behavior. Determine whether the documentation is still accurate and whether Promise or Guarantee results are unwrapped; done means a documented conclusion, with any required API or documentation scope identified.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

There's a blurb at the end of the Appendix document that reads:

So, if you want to start a chain by dispatching to the background, you have to use
DispatchQueue.async:

DispatchQueue.global().async(.promise) {
    return value  
}.done { value in
    //…
}

However, this function cannot return a promise because of Swift compiler ambiguity
issues. Thus, if you must start a promise on a background queue, you need to
do something like this:

Promise { seal in
    DispatchQueue.global().async {
        seal(value)
    }  
}.done { value in
    //…
}

Or more simply (though with caveats; see the documentation for wait):

DispatchQueue.global().async(.promise) {
    return try fetch().wait()
}.done { value in
    //…
}

However, you shouldn't need to do this often. If you find yourself wanting to use
this technique, perhaps you should instead modify the code for fetch to make it do
its work on a background thread.

I wasn't sure of the exact issue behind this caution, so I spent some time trying to reproduce it, without much luck. Is it possible that current compilers handle this situation more smoothly?

E.g., this seems to work fine:

DispatchQueue.global().async(.promise) {
    return Promise.value(42)
}.then {$0}.done { value in
    print(value)
}.catch { _ in }

If the situation is in fact better now, it might be nice if the async(.promise) family provided its own unwrapping when the return type of the closure was a Promise or Guarantee so that, e.g., the return type of

queue.async(.promise) { Promise.value(42) }

would be Promise<Int> rather than Promise<Promise<Int>>.

It's potentially a breaking change, but since the docs have historically warned away from this, maybe not a big deal for PMK7?

Lingua principale
Swift
Stelle
14.2k
Fork
1.5k
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di mxcl/PromiseKit

Tutte le issue di mxcl/PromiseKit

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.