lampepfl/dotty

This channel is now CLOSED. Please use gitter.im/scala/scala for user questions and gitter.im/scala/contributors for compiler development.

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

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!

Nicolas Rinaudo

@nrinaudo

https://contributors.scala-lang.org/t/could-adts-extend-product-with-serializable-in-dotty/3304
Be gentle

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)
  }
}

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.

Where communities thrive

People

Repo info

Activity