Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 02:11
    codecov-io commented #3208
  • 02:11
    codecov-io commented #3208
  • 02:11
    codecov-io commented #3208
  • 01:31
    codecov-io commented #3208
  • 01:31
    johnynek synchronize #3208
  • 01:31

    johnynek on defer_fix

    address Travis' comment (compare)

  • Dec 13 18:16
    codecov-io commented #3209
  • Dec 13 18:15
    codecov-io commented #3209
  • Dec 13 17:49
    travisbrown commented #3209
  • Dec 13 17:41
    travisbrown review_requested #3209
  • Dec 13 17:41
    travisbrown review_requested #3209
  • Dec 13 17:40
    travisbrown opened #3209
  • Dec 13 17:16

    travisbrown on master

    Avoid kind-projector syntax wit… (compare)

  • Dec 13 17:16
    travisbrown closed #3207
  • Dec 13 15:38
    codecov-io commented #3208
  • Dec 13 15:38
    codecov-io commented #3208
  • Dec 13 15:38
    codecov-io commented #3208
  • Dec 13 15:23
    codecov-io commented #3207
  • Dec 13 15:22
    codecov-io commented #3207
  • Dec 13 15:22
    codecov-io commented #3207
Daniel Spiewak
@djspiewak
I don't even care about them. I just worked around it by having a more first-class encoding
Guillaume Martres
@smarter
and it's not even clear that the concept of a "bare existential" without packing/unpacking can be sound
even java wildcards are barely understood in type theory
Daniel Spiewak
@djspiewak
you have to build some more useful calculus around it
basically it's when you already have a type constructor, F[_], with natural packing
in that case, Exists[F] can be meaningful
clearly something dumb like exists a . a is meaningless outside of weird curry-howard tricks
Guillaume Martres
@smarter
so that still works fine in Dotty if F is a class constructor
Daniel Spiewak
@djspiewak
oh yeah I can 100% make this work in Dotty
to be clear, just because Scala 2 has forSome doesn't mean it's necessarily useful in its current form
I mostly use it as a trick to get the typer to unify things that I want it to unify
and to work around bugs
the first-class Exists encoding that you see in skolems is a lot more useful
when you need the bare quantifier
and all of that is doable in Dotty
like, in a unicorn world where nsc fixed all its forSome-related bugs, it would be quite nice
but… that world won't happen, and if it were to happen, it's less practically useful than the world we actually have where Scala 3 gives up on that entirely and has a sane use of universals instead
so tldr, the skolems readme certainly isn't shilling for changes to Scala 3. I think it's fine the way it is :-)
Colt Frederickson
@coltfred
I saw here typelevel/cats#3143 that Cats 2.1.0 was planned by end of Nov. Is there anything holding it up?
Luka Jacobowitz
@LukaJCB
@coltfred we could probably release that in the next couple of weeks
Colt Frederickson
@coltfred
I don't have any personal urgency, just trying to plan for dropping 2.11 on cats-scalatest, which I'll do when 2.1 is out.
Travis Brown
@travisbrown
@coltfred I'd been wanting to get typelevel/cats#3150 and a couple of follow-up things merged first, but got distracted…
we've been using RC2 in production for about a week with no issues (after the bincompat trouble with RC1)
I'd be happy to go either way. I can plan to put some time into the Foldable laziness / short-circuiting stuff next week…
I'd prefer to hold 2.1.0 for that, but if anyone wants a non-RC sooner that's definitely fine with me.
Travis Brown
@travisbrown
(I'd also like to get #3186 #3187 #3190 #3191 and maybe #3193 merged first—they're all (except the last) pretty trivial and most already have one sign-off.)
Travis Brown
@travisbrown
what do you all think about publishing a 2.1.0-RC3 today or tomorrow?
I'd like to merge #3155 just to get it done (it's test-only), and I'm working on a follow-up to #3150 right now
oh, #3155 just got merged :smile:
Kai(luo) Wang
@kailuowang
Sounds good to me.
Luka Jacobowitz
@LukaJCB
:+1:
Travis Brown
@travisbrown
@LukaJCB what do you think about merging #3150? there are a couple of things that I think need adjusting but it'd probably be easiest to do those in a follow-up.
Travis Brown
@travisbrown
super easy one (method name in tests): typelevel/cats#3198
Travis Brown
@travisbrown
and here's the next, which fixes short-circuiting for these operations: typelevel/cats#3199
I've got one more, to clarify some of this stuff in the docs
Travis Brown
@travisbrown
okay, #3199 now includes the docs changes and is ready for review.
I've also opened a couple of related issues (#3200 and #3201) in case anyone has ideas
Travis Brown
@travisbrown
once #3199 is merged I'll start the 2.1.0-RC3 release unless anyone has objections?
Luka Jacobowitz
@LukaJCB
Go ahead :)
Travis Brown
@travisbrown
Travis Brown
@travisbrown
okay, I think this is the last of it: typelevel/cats#3203
Travis Brown
@travisbrown
I think we should start having the person who runs the release push the release commits directly to master
which breaks tags and means we have to force push the 2.1.x branch
I wish GitHub would let you force a specific merge type when you open a PR
Kai(luo) Wang
@kailuowang
yeah, that was my brain fart. I agree we need to find away to avoid this in the future. Maybe we should just let the release person merge release branch back to master without a PR? There is nothing to review anyway right?( except the release notes and update to docs which can be PRed against the release branch)?
Travis Brown
@travisbrown
I'm pretty sure pushing to master is disabled? I don't have the rights to check.
Kai(luo) Wang
@kailuowang
ah right, it’s protected branch and better remain that way.
I need to stop checking Cats from my phone. In the meantime let me dig into the settings.
Travis Brown
@travisbrown
The more reviews the better, from phone or wherever! This is a fairly unusual case.