Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 12:47
    nicolasstucki commented #10467
  • 12:38

    odersky on master

    Drop Scala2compat language feat… Make bootstrapped DottyPredef a… Drop scalaShadowing after boots… and 11 more (compare)

  • 12:38
    odersky closed #10428
  • 12:38
    odersky closed #10294
  • 12:37
    odersky synchronize #10458
  • 12:16
    nicolasstucki synchronize #10467
  • 12:12
    romanowski commented #10465
  • 12:07
    nicolasstucki commented #10467
  • 12:01
    odersky synchronize #10428
  • 11:54
    b-studios commented #10308
  • 11:50
    b-studios commented #10470
  • 11:33
    romanowski commented #10430
  • 11:28
    b-studios opened #10471
  • 11:26
    odersky synchronize #10458
  • 10:51
    nicolasstucki synchronize #10467
  • 10:45
    romanowski review_requested #10470
  • 10:45
    romanowski commented #10470
  • 10:45
    romanowski opened #10470
  • 10:45
    odersky synchronize #10458
  • 10:39
    liufengyun commented #10467
Lionel Parreaux
@LPTK

E.g. paolo saying "That still worries me"

If you went by only implementing features @Blaisorblade is not worried about, you'd only have half of the current features in Dotty :^P

Eshu
@eshu
Is it possible to use scalatest with 3.0.0-M1?
Lionel Parreaux
@LPTK
But seriously, this is the conservative thing to IMHO. I'm willing to bet that literally NO ONE ever "naturally" encountered a runtime exception because of the unsoundness of type projection. I think almost no one even uses them with lower-bounds

Regardless, there is absolutely no chance we have time to look at this before 3.0 is out, everyone is already working at 200% on getting the release out

It a shame the feature was summarily removed this way, but I guess we'll have to wait then!

Guillaume Martres
@smarter
@eshu yes, scalatest 3.2.3 is out for 3.0.0-M1
@LPTK feel free to make a pr to argue your case
I have five critical things in my head I need to deal with in the next few weeks before the RC1 release, I can't handle thinking about more things or my head will explode
Eshu
@eshu
@smarter Thank you very much!
Lionel Parreaux
@LPTK
@smarter Ok! Note that it's not really "my" case (I don't even use TP in projects I'd be willing to migrate soon), more like preserving the community from one more unnecessary paper cut they'll experience when migrating
Guillaume Martres
@smarter
I'm not happy about forcing people to change their code if they don't have to either
However not many people use projections heavily so it's not a huge deal either as far as I can tell
Lionel Parreaux
@LPTK
Right, many uses of the feature have become redundant. But not really all of them. So it's going to be painless for many, but very painful for a few (I'd guess mainly library designers/maintainers, whose interest you wouldn't want to lose)
megri
@megri
I posted some thoughts on the "as" keyword here: https://contributors.scala-lang.org/t/bikeshed-functionality-proposal-for-implicits/3893/8. There didn't seem to be a better suited unclosed thread available.
Rob Norris
@tpolecat
urgh is as a keyword now?
lots of libraries define methods called as
Michael Pilquist
@mpilquist
soft keyword, still safe to use as a method name
at least as of 3.0.0-M1
Rob Norris
@tpolecat
aha cool
Mikołaj Robakowski
@mrobakowski
Hey, extension blocks behave weirdly inside method bodies. Overloading doesn't work. It works as expected if you move the extension block outside the method. Is this by design or a bug? https://scastie.scala-lang.org/gfQr3rvtTEOyLCwW1mDbcw
Tom Grigg
@griggt
@kenbot seal was replaced by asExpr, asExprOf[T], and TypeRepr.asType. See lampepfl/dotty#10258, lampepfl/dotty#10278, lampepfl/dotty#10233
Rob Norris
@tpolecat
hm http://dotty.epfl.ch seems to be broken
is there somewhere else i should be looking?
Michael Pilquist
@mpilquist
wdym? note it was published via scala3doc for the first time today
Rob Norris
@tpolecat
if i click on docs it's empty
image.png
Guillaume Martres
@smarter
try another browser
I heard it's broken on safari
Michael Pilquist
@mpilquist
safari right? yeah what @smarter said
Rob Norris
@tpolecat
yeesh
Guillaume Martres
@smarter
Michael Pilquist
@mpilquist
the ToC is empty in firefox too, but sidebar works
Rob Norris
@tpolecat
does the repl not understand significant whitespace?
Guillaume Martres
@smarter
it does
Rob Norris
@tpolecat
```scala
scala> extension [A](a: A)
1 |extension [A](a: A)
  |                   ^
  |                   Extension without extension methods
```
Michael Pilquist
@mpilquist
Rob Norris
@tpolecat
you're fast
thx
Guillaume Martres
@smarter
ah I guess there's something missing for extensions
Michael Pilquist
@mpilquist
i'm like a week or two ahead is all: lampepfl/dotty#9878 (closed as dupe)
Rob Norris
@tpolecat
:-)
Guillaume Martres
@smarter
you can do shift+alt to get a new line in the repl without it being processed in any way
err, shift+enter
oh no it's alt+enter
Rob Norris
@tpolecat
cool that works
Alexander Ioffe
@deusaquilus
Please, oh please, oh please, could we make quoted matching type ascriptions covariant...
lampepfl/dotty#10464
noti0na1
@noti0na1
Where do handle this special case in the compiler? Int | Null is not a subtype of Int, but adaptToSubType seems not used here?
val x: Int | Null = 1
val y: Int = x
bmeesters
@bmeesters
I was looking at def summon[T <: AnyRef](implicit ev: T): ev.type = ev and was wondering why the return type is ev.type instead of just T? I have seen the pattern of using return type x.type more often but don't understand its use. Can somebody explain it to me?
Michał Pałka
@prolativ

@bmeesters this lets you get a more precise type when calling summon. E.g. with this traits hierarchy:

trait Foo
trait Bar extends Foo
given Bar = new Bar {}

the code below compiles

val x: Bar = summon[Foo]

but this doesn't

def wideSummon[T <: AnyRef](implicit ev: T): T = ev
val y: Bar = wideSummon[Foo]
bmeesters
@bmeesters
Thanks for the answer @prolativ . Though if Bar has methods that Foo does not have, will that not fail on runtime if you get a Foo, and type it as a Bar?
Michał Pałka
@prolativ

As Bar is a subtype of Foo, it's perfectly valid for it to have some methods that are absent from Foo. I assume you're considering a situation when we change

given Bar = new Bar {}

into

given Bar = new Foo {}

Then the compilation will fail at the level of given Bar.
If we try to fool the compiler like this

given Bar = (new Foo {}).asInstanceOf[Bar]

then the call to summon[Foo] will of course fail at runtime but widening the result type of summon as in wideSummon will not make it work