by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 01:13
    som-snytt commented #9200
  • Jul 13 23:00
    ekrich commented #7212
  • Jul 13 21:05
    nicolasstucki synchronize #8940
  • Jul 13 20:40
    b0bai starred lampepfl/dotty
  • Jul 13 20:24
    nicolasstucki synchronize #8940
  • Jul 13 19:56
    nicolasstucki synchronize #8940
  • Jul 13 19:49
    nicolasstucki synchronize #8940
  • Jul 13 19:26
    nicolasstucki synchronize #8940
  • Jul 13 19:04
    nicolasstucki synchronize #8940
  • Jul 13 18:45
    nicolasstucki synchronize #8940
  • Jul 13 17:53
    nicolasstucki synchronize #8940
  • Jul 13 17:22
    smarter commented #9359
  • Jul 13 17:19
    LPTK commented #9359
  • Jul 13 17:15
    odersky synchronize #9343
  • Jul 13 17:07
    odersky synchronize #9343
  • Jul 13 17:01
    smarter commented #9359
  • Jul 13 17:00
    LPTK commented #9359
  • Jul 13 16:59
    nicolasstucki synchronize #8940
  • Jul 13 16:58
    LPTK commented #9359
  • Jul 13 16:54
    smarter commented #9359
Nicolas Rinaudo
@nrinaudo
It does indeed
Guillaume Martres
@smarter
Because the unapply cannot fail, since it returns a Some it will always be used if the input has type One
Nicolas Rinaudo
@nrinaudo
isn't that making assumptions about unapply's body, such as the fact that it doesn't use reflection?
Guillaume Martres
@smarter
I'm not sure what you mean by that
Nicolas Rinaudo
@nrinaudo
probably nothing intelligent. Let's ignore it.
Guillaume Martres
@smarter
The unapply is a method that takes a One and returns a Some
Nicolas Rinaudo
@nrinaudo
but then - is it the Some type, or the shape of the type?
Guillaume Martres
@smarter
we know that an unapply succeeds if it returns a Some
if we know statically that it returns a Some then we know statically that it cannot fail
Nicolas Rinaudo
@nrinaudo

we know that an unapply succeeds if it returns a Some

This is what I'm struggling with. I thought dotty's pattern matching didn't rely on Option

Guillaume Martres
@smarter
Some is special-cased exactly for this reason.
Nicolas Rinaudo
@nrinaudo
OK, that was exactly what I was struggling with
Option-less pattern matching
Nicolas Rinaudo
@nrinaudo
this lead me to believe that pattern matching didn't rely on Option, when it meant it can work without Option
Guillaume Martres
@smarter
yes
Nicolas Rinaudo
@nrinaudo
ok, so that clarifies everything. I was stuck by the fact that it magically worked without special casing Some
thank you for your time and explanations
Guillaume Martres
@smarter
:)
it's true that http://dotty.epfl.ch/docs/reference/changed-features/pattern-matching.html is missing documentation on the concept of an irrefutable apply
Nicolas Rinaudo
@nrinaudo
I would actually really like to know more about that, and how the behaviour changed since Scala 2. It clearly changed, and I'd love to know to what extent
Guillaume Martres
@smarter
Opened an issue: lampepfl/dotty#6490
Nicolas Rinaudo
@nrinaudo
the code you linked clarifies it quite a bit as well, thanks
I have another, entirely unrelated question. Is there a particular reason for enum types not to extend Serializable and, when all cases are products, Product?
Guillaume Martres
@smarter
no particular reason
Nicolas Rinaudo
@nrinaudo
is this something that could be considered?
scala> enum Foo {
     |   case Bar(i: Int)
     |   case Baz(b: Boolean)
     | }
     | 
     | List(new Foo.Bar(1), new Foo.Baz(true))
// defined class Foo
val res1: List[Foo & Product & Serializable] = List(Bar(1), Baz(true))
I was really hoping for the Product & Serializable wart to disappear :/
Guillaume Martres
@smarter
if you don't use new then you get the apply companion that returns Foo so you just have a List[Foo]
Nicolas Rinaudo
@nrinaudo
absolutely. The wart is better hidden, but it's still here
Guillaume Martres
@smarter
but if no one uses new, then is it really worth the effort to special-case Serializable and Product in enums ?
it'd be more interesting to do this for regular sealed traits
but then it still seems a weird special-casing than you cannot opt out of
Nicolas Rinaudo
@nrinaudo
if it's complicated, probably not. But if not, and you already have a special case for case classes, why not special case ADTs?
Guillaume Martres
@smarter
what do you mean by special case for case classes ?
Nicolas Rinaudo
@nrinaudo
case classes are Product with Serializable, right?
Guillaume Martres
@smarter
it's not complicated to implement, it's just irregular
yes
but that's unconditional
Nicolas Rinaudo
@nrinaudo
I'm arguing Serializable should then be unconditional for enums
Product is slightly weirder, since not all cases need be products
Guillaume Martres
@smarter
what if I extend something which is impossible to serialize ?
Martijn Hoekstra
@martijnhoekstra
if all members of some sealed trait Foo extend Bar, then Foo extends Bar naively sounds like a reasonable rule that would solve all potential issues
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)