Erik Bruchez

I was playing with async/await and this is one of the first questions that popped up. So :+1: to improve this.

FWIW I used @danarmak's solution above: ``` scala await(kittens() map Success.apply recover PartialFunction(Failure.apply)) match { case Failure(t) ⇒ // ... case Success(v) ⇒ // ... } ``` But a `tryAwait`...

Following this as, to my surprise, checking the generated .ll code, I noticed see that indeed every `.toUInt` generates an object allocation from the heap.

I know know much about compatibility implications but otherwise I don't see a problem with making performance better when using Scala 3.

This appears to have been addressed in `Throwables.scala`: https://github.com/scala-native/scala-native/blob/0902082a86693fea8f689adab4a8867def226514/javalib/src/main/scala/java/lang/Throwables.scala#L41-L52 There is still stack allocation in the `test-interfaces` project: https://github.com/scala-native/scala-native/blob/0902082a86693fea8f689adab4a8867def226514/test-interface/src/main/scala/scala/scalanative/testinterface/signalhandling/SignalConfig.scala#L79-L80

I don't understand enough to say, but there is a comment in `SignalConfig` about "using only async-signal-safe methods". If this is still valid, then might two different implementations be justified?...

I got here because I was wondering which backend is used on the JVM. I appreciate that just depending on `HttpURLConnection` has the benefit of minimal dependencies and will work...

I just found out about the [Google HTTP Client Library for Java](https://github.com/google/google-http-java-client). It features a "Pluggable HTTP transport abstraction that allows you to use any low-level library such as `java.net.HttpURLConnection`,...

@hmil Thanks for the heads-up.

Workaround: ``` headers.asInstanceOf[fr.hmil.roshttp.util.HeaderMap[Any]].get("Set-Cookie") map (_.asInstanceOf[js.Array[String]]) ```