Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:00
    nicolasstucki synchronize #14002
  • 14:58
    Kordyjan review_requested #14356
  • 14:58
    Kordyjan opened #14356
  • 14:58
    Kordyjan review_requested #14356
  • 14:55
    Sporarum synchronize #14019
  • 14:53
    odersky ready_for_review #14330
  • 14:49
    dwijnand commented #14347
  • 14:49

    odersky on master

    Avoid unnecessary under-constra… Merge pull request #14353 from … (compare)

  • 14:49
    odersky closed #14353
  • 14:49
    odersky closed #14333
  • 14:37
    Kordyjan edited #14311
  • 14:37
    odersky edited #14335
  • 14:37
    Kordyjan edited #14311
  • 14:35
    nicolasstucki synchronize #14002
  • 14:34
    odersky ready_for_review #14335
  • 14:34
    odersky labeled #14335
  • 14:23
    armanbilge synchronize #14071
  • 14:17
    odersky synchronize #14335
  • 14:16
    odersky synchronize #14330
  • 14:15

    odersky on cc-experiment

    Move elim repeated earlier Thi… Update analyzer plugin Fix import in analyzer plugin and 23 more (compare)

Olivier ROLAND
@newca12
@benhutchison @andreak @smarter I will fix the doc
Guillaume Martres
@smarter
Thanks!
Olivier ROLAND
@newca12
Ólafur Páll Geirsson
@olafurpg
FYI, it looks like Scastie supports now the latest Dotty https://scastie.scala-lang.org/ZDPtyziPSAqXM8OrPy9ZNA
Nicolas Rinaudo
@nrinaudo
I (think I) understand match types, but I'm not super clear on the point of them. Is there a motivating example, or existing Scala patterns that are made clearer / simpler by their addition?
Miles Sabin
@milessabin

Here's something I'm experimenting with,

  type LiftP[F[_], T] = T match {
    case Unit => Unit
    case (a, b) => (F[a], LiftP[F, b])
  }

This is much simpler than the equivalent using implicit induction and path dependent types.

Nicolas Rinaudo
@nrinaudo
err... so. This lifts all the components of tuple type T into type constructor F?
Miles Sabin
@milessabin
Exactly.
ml10
@ml10
@milessabin Curious if you and Edwin Brady are considering a reprise of your Scala/Idris talk from 2013 once Dotty and Blodwen are out. :)
Nicolas Rinaudo
@nrinaudo
@milessabin any reason other than this is just a quick sample I typed for you not to declare T <: Tuple?
Miles Sabin
@milessabin
It's not something I've thought about or we've discussed, but that's not a bad suggestion :-)
@nrinaudo the bound is redundant given the cases.
ml10
@ml10
Nice! Of course I undertand if it doesn’t happen, but I think it would be enlightening.
Nicolas Rinaudo
@nrinaudo
In that case, I'm not sure why it's not infered, at least for Xs, in the dotty documentation:
 type Concat[+Xs <: Tuple, +Ys <: Tuple] <: Tuple = Xs match {
    case Unit => Ys
    case x *: xs => x *: Concat[xs, Ys]
  }
ah. Tuple arity?
Miles Sabin
@milessabin
I think the bound on Xs might be redundant there. But the bound on Concat is needed to satisfy the bound on the RHS of *: and that means that we need the bound on Ys for the Unit case.
Bounds are infectious.
Nicolas Rinaudo
@nrinaudo
That makes sense. Thank you!
Xavier GUIHOT
@xavierguihot

Hi, would there be a way, via the new export feature to achieve smthg like:

final class MyClass(a: String) { def f = println(a) }
trait MyTrait { def g = println("boo") }
val x = new MyClass("hello world")
class MixMyTrait[T](x: T) extends MyTrait { export x._ }
new MixMyTrait(x).f
|^^^^^^^^^^^^^^^^^^^
|value f is not a member of MixMyTrait[T]

I tried with a ClassTag as well, but doesn't help

Xavier GUIHOT
@xavierguihot
Hi, will it be possible to also use vararg patterns on case classes:
case class Point(x0: Int, x1: Int, x2: Int, x3: Int, x4: Int)
Point(1, 2, 3, 4, 5) match { case Point(x, rest: _*) if x > 0 => true; case _ => false }
                                  ^^^^^^^^^^^^^^^^^^
  // Wrong number of argument patterns for Point; expected: (Int, Int, Int, Int, Int)
Ghost
@ghost~54f4b69115522ed4b3dcb16d

@xavierguihot compare scalac -Xlint

scala> case class C(i: Int, js: Int*)
defined class C

scala> C(42) match { case C(x, y, rest @ _*) => }
                          ^
       warning: Sequence wildcard (_*) does not align with repeated case parameter or extracted sequence; the result may be unexpected.
scala.MatchError: C(42,ArraySeq()) (of class C)
  ... 30 elided

and dotty

scala> case class C(i: Int, js: Int*)
// defined case class C

scala> C(42) match { case C(x, y, rest : _*) => }
1 |C(42) match { case C(x, y, rest : _*) => }
  |                   ^^^^^^^^^^^^^^^^^^
  |            Wrong number of argument patterns for C; expected: (Int, Int*)

I haven't followed the changes, but indiscriminate scarfing of pattern args is pretty dicey.

Xavier GUIHOT
@xavierguihot
This would mean using a vararg definition of the class parameter though; seeing the List example in dotty's doc, I'm wondering if it would be possible to do the same on a classical case class
Ghost
@ghost~54f4b69115522ed4b3dcb16d
@xavierguihot I meant to suggest that the usual expectation is that the pattern "looks like" the constructor. If they don't align, it's confusing and error-prone. Since they tightened the case of varargs, it's even less likely they would extend the syntax for the case you propose.
Ben Hutchison
@benhutchison

Ive started experimenting with Dotty in VSCode. Im really impressed by the library compatibility with Scala 2.x using withDottyCompat in build.sbt. I have been able to throw Typelevel libs into a Dotty project and so far (almost) everything "just works"...

.. but it seems like the IDE isn't reloading/reimporting build.sbt changes, as editor is complaining about missing library imports, while SBT CLI is fine. Is there a key-combo I should hit to trigger reimport of the SBT build?

Ben Hutchison
@benhutchison
.. seems like closing the project and SBT> launchIDE does it
Guillaume Martres
@smarter
@benhutchison Yes, right now you'll need to do launchIDE(which should restart vscode too)
deeper build tool integration requires something like https://github.com/scalacenter/bsp/ which I'm desperately hoping sbt will implement one day
Nicolas Rinaudo
@nrinaudo
am I correct in my understanding that in dotty, the following syntax for structural types is not possible anymore?
def foo(x: {def getInt: Int}): Int = x.getInt
I'm specifically talking about the structural type declaration - it must be prefixed by a type that is a subtype of Selectable now?
Nicolas Rinaudo
@nrinaudo
Ah. scala.reflect.Selectable.reflectiveSelectable
Nicolas Rinaudo
@nrinaudo
I'm probably missing something very obvious, but I don't understand by what mechanism the reflection-based Selectable instance manages to fail at compile time...
Nicolas Rinaudo
@nrinaudo
ok, now that I think I understand all this a bit better, I realise my questions make no sense. Apologies :/
Nicolas Rinaudo
@nrinaudo

Gitven the following code:

object ExtractSome {
  def unapply[A](s: Some[A]): Option[A] = s
}

def unwrap(oi: Option[Int]): Int = oi match {
  case ExtractSome(i) => i
}

I get the following warning:

[warn] -- [E029] Pattern Match Exhaustivity Warning: /home/nicolas/dev/nrinaudo/test/dotty/src/main/scala/PattMatch.scala:6:37 
[warn] 6 |  def unwrap(oi: Option[Int]): Int = oi match {
[warn]   |                                     ^^
[warn]   |                             match may not be exhaustive.
[warn]   |                             
[warn]   |                             It would fail on pattern case: _: Option[Int]
it's an improvement on Scala 2 who'd not warn at all, but the pattern case is weird - it doesn't fail on any Option[Int], it specifically fails on None
if I change the return type of ExtractSome.unapply to Some[A], I do get the warning I'd expect:
[warn] -- [E029] Pattern Match Exhaustivity Warning: /home/nicolas/dev/nrinaudo/test/dotty/src/main/scala/PattMatch.scala:6:37 
[warn] 6 |  def unwrap(oi: Option[Int]): Int = oi match {
[warn]   |                                     ^^
[warn]   |                                     match may not be exhaustive.
[warn]   |                                     
[warn]   |                                     It would fail on pattern case: None
is that normal or expected behaviour?
Srepfler Srdan
@schrepfler
peeps, JavaScript these days has some pretty nice syntactic sugar for destructuring of objects and arrays, what if we try to introduce their syntax in scala 3?
Jamie Thompson
@bishabosha
@schrepfler would that be for dynamic interfaces like json decoding?
Guillaume Martres
@smarter
@nrinaudo Yes. How can the compiler know that your custom unapply will not fail on Some if it returns an Option ?
Nicolas Rinaudo
@nrinaudo
understood. Thank you!
Nicolas Rinaudo
@nrinaudo
mmm...
actually, how does it know that the custom unapply will not fail on Some, even if it returns a Some?
Guillaume Martres
@smarter
Because it takes Some as input
this would be less confusing if you were matching on something other than Option :)
Nicolas Rinaudo
@nrinaudo
it's a bit confusing, yes :)
let me try and play with it a bit more
Nicolas Rinaudo
@nrinaudo

If I change my unapply to:

    def unapply[A](o: Option[A]): Some[A] = o match {
      case s: Some[A] => s
      case _ => sys.error("fail")
    }

I don't get a warning. I understand that as far as the types are concerned, this makes sense, but how does the compiler know without special handling of Some?

Guillaume Martres
@smarter
this is too confusing to explain when you're matching on an Option
Nicolas Rinaudo
@nrinaudo
OK. Is it alright to still use an Option or a Some as the return type though?
Guillaume Martres
@smarter
here's a better example:
sealed trait Foo[A]
case class One[A](a: A) extends Foo[A]
case class Two[A](a: A) extends Foo[A]

object ExtractOne {
  def unapply[A](s: One[A]): Some[A] = Some(s.a)
}

def unwrap(fi: Foo[Int]): Int = fi match {
  case ExtractOne(i) => i
}