## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
• 17:04
dwijnand synchronize #14820
• 15:10
anatoliykmetyuk synchronize #15684
• 14:37
dwijnand assigned #15851
• 14:37
dwijnand review_requested #15851
• 14:37
• 14:36
dwijnand synchronize #14820
• 13:20
sjrd commented #15850
• 13:02
anatoliykmetyuk synchronize #15684
• 12:55
bishabosha edited #15847
• 12:55
bishabosha synchronize #15847
• 12:41
dwijnand synchronize #15851
• 12:15
anatoliykmetyuk synchronize #15684
• 11:23
odersky synchronize #15844
• 11:20
abgruszecki commented #14820
• 10:43
dwijnand opened #15851
• 10:17
som-snytt commented #11041
• 10:09
ALPSMAC edited #15846
• 09:55
KacperFKorban labeled #15850
• 09:09
Kordyjan closed #15820
• 09:09
julienrf commented #15611
Guillaume Martres
@smarter
PR to update broken links are welcome
Xavier GUIHOT
@xavierguihot
Hi, playing with the new parameter untupling feature; any plans to also have the possibility to do this in the future?
def f(a: Int, b: Int): Int = a * b
List((1, 2), (3, 4)).map(f(_, _ * 2))
Guillaume Martres
@smarter
good question, I'm not sure
odersky
@odersky
No, that can’t work. _ is used on two different levels here. So its translation is
x => f(x, y => y * 2))
Guillaume Martres
@smarter
ah right
Ghost
@ghost~54f4b69115522ed4b3dcb16d
I'm happy that in Scala 3, underscore still has levels. Is it too late to propose double-underscore syntax __ * 2 to mean expanding to the next enclosing Expr? Inductively for ___ and up, of course. I guess that would make arbitrarily long underscores reserved. That's OK, because then usage of case _________ => for alignment purposes can be more narrowly defined for the default case.
Soren
@srnb_gitlab
I'd be a fan of expanded underscore
Harrison Houghton
@hrhino
What about requesting no underscore? So you have something like case if ... =>
:D
Martijn Hoekstra
@martijnhoekstra
you just repeat the no underscore to mean expanding to the next Expr?
I like that
Ghost
@ghost~55118a7f15522ed4b3ddbe95
@hrhino why stop there m match { x => ...; if p => ...; Some(y) => ... }
Ghost
@ghost~54f4b69115522ed4b3dcb16d
@hrhino I can't tell if you're getting my goat. scala/scala#6241
Harrison Houghton
@hrhino
I'm getting your goat, but in a sympathetic way.
I did see that PR.
Ghost
@ghost~54f4b69115522ed4b3dcb16d
@hrhino then you meant GOAT.
Denis Rosset
@denisrosset
Small question: how well do inline and @specializedplay together? I wrote a small library for specialized collections and used macro trickery to escape most specialization problems ( https://github.com/denisrosset/metal -- warning the macro use is quite gross).
Guillaume Martres
@smarter
Right now there is zero support for @specialized in Dotty
Denis Rosset
@denisrosset
Now, I'd like to see how inline can improve over that; but it seems to be applied at a stage where specialization cannot be recovered.
OK! thanks
So I'll stop looking.
Guillaume Martres
@smarter
And no immediate plan to bring it back
because it's a huge mess
method specialization is OK, but specializing non-final classes is really hard and even after years of work not completely correct in Scala 2
I'm assuming you're looking at this for Spire ? What kind of specialization do you use ? Have you checked how much it's still needed when using Graal for example ?
Denis Rosset
@denisrosset
Yes it is.. what I did in metal was to have nonspecialized traits, but specialized methods... so you call (set: MySet[A]).contains[A](a), where the first type parameter is nonspecialized (MySet[A]), but the magic happens in the def contains[@specialized B](b: B). The macro system is there to put the right type parameters.
My immediate problem with Scala specialization was that Map[@sp A, @sp B] fails to specialize for e.g. Map[AnyRef, Int].
Guillaume Martres
@smarter
that's interesting
Denis Rosset
@denisrosset
Spire behaves better in that respect: it's often pretty clear which type parameters would be scalars, and then we specialize only those.
But indeed, Spire on Dotty is an interesting thought. I have a talk at the ScalaDays about Spire generic approach. I haven't tried Dotty on it, neither Graal, that's an excellent suggestion.
Guillaume Martres
@smarter
Given your experience, it'd be great if you could write up what you think the compiler should provide in terms of specialization
maybe as a starting point for a discussion on https://contributors.scala-lang.org/
Denis Rosset
@denisrosset
Let me think of it. Will you be there at the Scala Days?
Guillaume Martres
@smarter
yep!
it's basically happening in my backyard so hard to miss it
Denis Rosset
@denisrosset
Ha!
I wonder if I'll have time to deeply think about specialization till the conference .. anyway, I'll dig into the generated bytecode, assembly for numerical code. While the presentation won't address specialization directly, it will give us food for thought!
Guillaume Martres
@smarter
sounds good!
Matthew Pickering
@mpickering
Does anyone know why the type representation is indexed by a type rather than its kind? How does the type system ensure that type splices are well-typed?
Dermot Haughey
@hderms
is it likely dotty will actually be faster to compile than scala 2?
Guillaume Martres
@smarter
right now they're about the same speed
so probably not, though we may get parallelization working well enough: lampepfl/dotty#4767
also if you're interested in speeding up either scala 2 or dotty, consider using graal: https://medium.com/graalvm/compiling-scala-faster-with-graalvm-86c5c0857fa3
Jamie Thompson
@bishabosha
@smarter has the effects “documentation” been erased, I knew it wasn’t concrete but is it dead?
Guillaume Martres
@smarter
don't know which documentation page you have in mind
Jamie Thompson
@bishabosha
it used to be on the overview
I was using it as a reference but maybe I shouldn’t because its too early
Guillaume Martres
@smarter
don't know what happened, you'll have to dig in the git history
odersky
@odersky
Effects won'’t make it for 3.0, but we keep working on them.