Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 11:58
    odersky opened #8679
  • 11:11
    unkarjedy edited #8677
  • 11:10
    unkarjedy commented #8678
  • 11:09
    unkarjedy labeled #8678
  • 11:09
    unkarjedy opened #8678
  • 10:54

    smarter on master

    Turn mismatch given errors into… Merge pull request #8611 from s… (compare)

  • 10:54
    smarter closed #8611
  • 10:54
    smarter closed #8053
  • 10:51
    bishabosha closed #6643
  • 10:51

    bishabosha on master

    fix #6643: add regression test Merge pull request #8676 from d… (compare)

  • 10:51
    bishabosha closed #8676
  • 10:26
    unkarjedy commented #8677
  • 10:23
    unkarjedy labeled #8677
  • 10:23
    unkarjedy opened #8677
  • 10:19
    sjrd commented #8348
  • 10:17
    bishabosha edited #8118
  • 10:15
    bishabosha commented #8348
  • 10:12
    sjrd commented #8348
  • 10:06
    bishabosha commented #6643
  • 10:05
    bishabosha reopened #6643
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
Nicolas Rinaudo
@nrinaudo
I'm being dense. Of course ADTs don't have a maximum depth of 1, since nothing prevents product types from having sum type fields
Guillaume Martres
@smarter
yeah
Nicolas Rinaudo
@nrinaudo
I don't know whether this even makes sense...
sorry, back to my cave!
Josh
@joshlemer
@nrinaudo I think the nested enums idea is nice and would be very useful
Nicolas Rinaudo
@nrinaudo
when? :)
Why not declare them at the "root"? isn't a bit like the difference between (A | B) | C and A | B | C?
Sébastien Doeraene
@sjrd
Nested enums are only useful if one uses the intermediate types; but since enums are defined in a way that tends to hide the types of specific cases, talking about the intermediate types does not make much sense.
Josh
@joshlemer
what about Paul Philips' SizeInfo example
enum SizeInfo {
  case Bounded(bound: Int)
  enum Atomic {
    case Infinite
    case Precise(size: Int)
  }
}
or
enum Ior[+A, +B] {
  case Both(left: A, right: B)
  enum Either[+A, +B] {
    case Left[+A, +B](value: A)
    case Right[+A, +B](value: B)
  }
}
Nicolas Rinaudo
@nrinaudo
The weird thing is, this compiles
Sébastien Doeraene
@sjrd
What do you expect the type of Left(5) to be? Should it be Either[Int, Nothing] or should it be Ior[Int, Nothing]? I argue that the former does not make sense, because Either sits at the same level as Both, but Both is not exposed as a type. And if the type of Left(5) is Ior anyway, then what good is Either?

The weird thing is, this compiles

Probably a missing check rather than an intentional thing.

Nicolas Rinaudo
@nrinaudo
Both is exposed as a type, isn't it?
Josh
@joshlemer
I thought it should be Either[Int, Nothing] and also thought Both would be exposed as a public type
Sébastien Doeraene
@sjrd
Kind of. It exists, but the type of Both(5, "foo") will be Ior[Int, String], not Both[Int, String], so you rarely observe Both. Why then should you observe Either?
Nicolas Rinaudo
@nrinaudo
new Both(5, "foo"): Ior.Both[Int, String] though
Josh
@joshlemer
Because the entire point of the nested enums is, as you said, to use intermediate types
Sébastien Doeraene
@sjrd
Yes that would be the point, but it's weird that we refuse to infer the concrete cases, but we're fine with inferring the intermediate types. It's very inconsistent.
It would make a lot more sense if the apply methods were typed as their individual cases, like they are for current case classes.
But people don't want that, apparently, so...
Nicolas Rinaudo
@nrinaudo
Dotty doesn't really refuse to infer the internmediate types though, does it?
enum Foo {
  case Bar(i: Int)
  case Baz(b: Boolean)
}


scala> List(new Foo.Bar(1), new Foo.Baz(false))
val res3: List[Foo & Product & Serializable] = List(Bar(1), Baz(false))
or am I using a wrong definition of the term?
Martijn Hoekstra
@martijnhoekstra
I'm still not entirely sure what the problem is with inferring List[Foo & Product & Serializable] if that's what it is
Nicolas Rinaudo
@nrinaudo
oh, my example makes no sense. Sorry, ignore that.
@martijnhoekstra it's not so much a problem as something supremely confusing for beginners
Josh
@joshlemer
I also think it's fine to have both available. If someone is going out of their way to say new Foo.Bar(1) rather than Foo.Bar(1) they might want that specific type
Nicolas Rinaudo
@nrinaudo
sorry, didn't mean to derail the conversation back to LUBs with my ill-thought example
Josh
@joshlemer
the rule could be to infer the most specific enum possible (so don't infer leaf nodes/case classes)
Martijn Hoekstra
@martijnhoekstra
also, should val ls: List[Serializable] = List(new Foo.Bar(1)) compile? If not, why not, and what's the alternative?
Nicolas Rinaudo
@nrinaudo
This message was deleted
@martijnhoekstra it should. My argument is that I'd like Foo to be a subtype of Product with Serializable
Nicolas Rinaudo
@nrinaudo
I might have missed something, but I was under the impression this was being deprecated / dropped?
scala> Seq(1) + 2                                                                                                                      
1 |Seq(1) + 2
  |         ^
  |         Found:    Int(2)
  |         Required: String
Guillaume Martres
@smarter
@nrinaudo It's deprecated in the 2.13 collections, Dotty still builds against the 2.12 collections
Srepfler Srdan
@schrepfler
Json extraction what’s used in JS world most commonly yes, it’s like fancy pattern matching and extracting with succinct syntactic sugar. I guess it could work for other things with named properties if you don’t need to pass around the whole instances around