It's better if it's traverse! (no, really)

By traversing on the entry's TTL we get the opportunity to avoid
calculating the time in case there's no TTL. That might give us some
extra performance in case of infinitely long-lived keys.

The constraint is more powerful, but all the caching implementations
will be at least monads, so it's fine. And Clock is only possible to
implement in a real scenario for instances of Sync.

Author: kubukoz

modules/core/shared/src/main/scala/scalacache/Entry.scala

@@ -1,11 +1,11 @@
 package scalacache
 
-import java.time.{Instant}
+import java.time.Instant
 import cats.effect.Clock
 import java.util.concurrent.TimeUnit
 import cats.implicits._
 import language.higherKinds
-import cats.Functor
+import cats.Applicative
 
 /**
   * A cache entry with an optional expiry time
@@ -15,6 +15,10 @@ case class Entry[F[_], +A](value: A, expiresAt: Option[Instant]) {
   /**
     * Has the entry expired yet?
     */
-  def isExpired(implicit clock: Clock[F], functor: Functor[F]): F[Boolean] =
-    clock.monotonic(TimeUnit.MILLISECONDS).map(Instant.ofEpochMilli(_)).map(now => expiresAt.exists(_.isBefore(now)))
+  def isExpired(implicit clock: Clock[F], applicative: Applicative[F]): F[Boolean] =
+    expiresAt
+      .traverse { ttl =>
+        clock.monotonic(TimeUnit.MILLISECONDS).map(Instant.ofEpochMilli(_)).map(ttl.isBefore(_))
+      }
+      .map(_.contains(true))
 }