Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 08 21:12
    sirocchj opened #8701
  • Apr 08 21:02
  • Apr 08 20:56

    odersky on master

    remove SCALA2X tag in TASTy Merge pull request #8699 from d… (compare)

  • Apr 08 20:56
    odersky closed #8699
  • Apr 08 20:55
    odersky synchronize #8700
  • Apr 08 20:25
    odersky commented #8571
  • Apr 08 20:23
    odersky commented #8571
  • Apr 08 20:23
    odersky commented #8571
  • Apr 08 20:18
    odersky commented #8700
  • Apr 08 20:15
    odersky synchronize #8700
  • Apr 08 20:10
    odersky opened #8700
  • Apr 08 19:45
    rjolly commented #76
  • Apr 08 17:06
    LPTK commented #76
  • Apr 08 16:43
    rjolly commented #76
  • Apr 08 16:29
    bishabosha assigned #8699
  • Apr 08 16:26
    bishabosha review_requested #8699
  • Apr 08 16:26
    bishabosha opened #8699
  • Apr 08 15:39
    liufengyun opened #8698
  • Apr 08 15:31
    LPTK commented #76
  • Apr 08 15:04

    nicolasstucki on master

    Add ujson to the community build Merge pull request #8697 from d… (compare)

Nicolas Rinaudo
@nrinaudo
don't you have the same problem with case classes?
Guillaume Martres
@smarter
@martijnhoekstra It's not completely crazy but it has the potential to break stuff
yes, you're not supposed to do that with case classes
Nicolas Rinaudo
@nrinaudo
so that's where my point of case classes are a special case came from
I was suggesting to make them less of a special case, or at least to make ADTs a special case, not just case classes
I do understand your point about breaking stuff though. I'm just not sure you'd break more stuff than currently
(I also understand that this kind of decision cannot be taken on a hunch)
Guillaume Martres
@smarter
no, you'll have to go to https://contributors.scala-lang.org/ and convince people to care :)
Nicolas Rinaudo
@nrinaudo
Ah. I thought this was the right avenue for that
ok then, thanks!
@smarter I think I'll end up crediting you for half of my slides at scaladays
Guillaume Martres
@smarter
haha
what's the topic of your talk ?
Nicolas Rinaudo
@nrinaudo
Best Practices I wish someone'd told me about
stuff like... extends Product with Serializable for ADTs
Guillaume Martres
@smarter
nice
Nicolas Rinaudo
@nrinaudo
or return Some when you can in extractors
there's a bit of a pattern :)
I'm trying to see how much of my deck is made irrelevant by dotty
Guillaume Martres
@smarter
One idea to get rid of Serializable showing up in type inference was to just add it as a parent of case clases after typechecking
since it's basically an implementation detail that no one cares about
Nicolas Rinaudo
@nrinaudo
people that work with Spark apparently care about it quite a bit
but yes, that'd work as well
Guillaume Martres
@smarter
they care about things extending Serializable
Nicolas Rinaudo
@nrinaudo
doesn't help with Product though
Guillaume Martres
@smarter
yeah I don't know what to do with Product
Nicolas Rinaudo
@nrinaudo
it's not a big deal, it's just very confusing for newcomers
Guillaume Martres
@smarter
might become irrelevant with the generic derivation stuff in dotty, or might not
agreed
hence why I think it's worth discussing on http://contributors.scala-lang.org/
Nicolas Rinaudo
@nrinaudo
and since I do a lot of work with beginners, it's something I have to explain again and agani, which is why I care
oh I absolutely intend to
(the generic derivation stuff in dotty is amazing to use, but looks absolutely nightmarish to write)
Guillaume Martres
@smarter
the idea so far is to have something really low-level in the compiler and higher-level shapeless-like things on top
Nicolas Rinaudo
@nrinaudo
that's what I've read, yes
Guillaume Martres
@smarter
Miles will be talking about that at scala days
Nicolas Rinaudo
@nrinaudo
oh cool
be honest - you guys designed match types specifically for him, right?
Guillaume Martres
@smarter
hah, kind of I guess
Nicolas Rinaudo
@nrinaudo

regarding enum, is there a syntax to define sum types within sum types? I was expecting:

  enum Foo {
    case Bar
    enum Baz {
      case Baz1
      case Baz2
    }
  }

But then this does not compile:

  val t: Foo = Foo.Baz.Baz1
Guillaume Martres
@smarter
no, that doesn't exist so far
Nicolas Rinaudo
@nrinaudo
ah. So ADTs declared via enum have a maximum depth of 1 at the moment
is there any plan to change that?
Guillaume Martres
@smarter
no one is working on that
or even suggested that
as far as I can tell
Nicolas Rinaudo
@nrinaudo
how upset do you think people would be if I suggested it?
Guillaume Martres
@smarter
shame on your family for ten generations
Nicolas Rinaudo
@nrinaudo
I assumed as much
Guillaume Martres
@smarter
seriously there's been so many discussions related to enum that I have no idea if this was discussed so far, so I'd say make a topic on https://contributors.scala-lang.org/ and see what happens