Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:42
    bishabosha edited #7760
  • 15:41
    bishabosha assigned #7760
  • 15:41
    bishabosha assigned #7760
  • 15:39
    bishabosha labeled #7760
  • 15:39
    bishabosha opened #7760
  • 14:21
    brunnerant synchronize #7732
  • 14:08
    odersky edited #7759
  • 14:07
    odersky edited #7759
  • 14:06
    odersky edited #7759
  • 14:06

    odersky on master

    Handle nullability info in by-n… Refine by-name handling and add… Move postProcessByNameArgs to N… and 2 more (compare)

  • 14:06
    odersky closed #7727
  • 13:44
    odersky opened #7759
  • 13:34
    odersky edited #7727
  • 13:24
    odersky synchronize #7727
  • 12:47
    odersky synchronize #7727
  • 12:41
    odersky synchronize #7727
  • 09:53
    odersky synchronize #7727
  • 09:50
    odersky closed #7546
  • 09:38
    som-snytt edited #7758
  • 09:32
    som-snytt labeled #7758
Tim Pigden
@tim.pigden_gitlab
thanks. I do need multiple fields and can't wait. So I guess I'll have to look elsewhere.
Guillaume Martres
@smarter
there's no solution
if all your fields are of the same type, you can make an array of that type
if they're different types, you can make multiple arrays
Tim Pigden
@tim.pigden_gitlab
I've tried the multiple array approach. Code quickly got seriously hard to make readable and in the end I gave up. Also tried a flyweight "cursor" type approach where the trait was implemented on top of a primitive array with behind the scenes type castes to primitive fields. But likewise it got too complicated. By "elsewhere" I meant another language. My colleague's been learning Rust but I didn't want to commit to a different language unnecessarily.
Guillaume Martres
@smarter
Yeah, I'd go with Rust too if I really needed this
Oron Port
@soronpo
Why there is this limitation: Implementation restriction: No inline methods allowed where opaque type aliases are in scope ?
I wanted to try the following:
import compiletime._

opaque type Positive = Int
object Positive {
  inline def apply[T <: Int](value : T) : Positive = {
    inline if (value <= 0) error(code"failed on: $value")
    else value
  }
}

val eight = Positive(8)
val negError = Positive(-1)
jeremyrsmith
@jeremyrsmith
I guess if you inline that apply then the place where it would be inlined wouldn’t be able to see that Positive is Int (unless you were invoking apply from inside the companion)
Paolo G. Giarrusso
@Blaisorblade
if so, that could be relaxed for private, if needed?
but if @jeremyrsmith's is the motivation (and it makes sense to me), it shouldn't be an "Implementation restriction" — that's a conceptual limitation, since inline in Dotty is designed to preserve typability IIRC
Oron Port
@soronpo
I see no semantic problem in the code I wrote. It's something that should be expressible, IMO.
Paolo G. Giarrusso
@Blaisorblade
@soronpo IMO, what @jeremyrsmith said makes perfect sense. I mean, it’s clear the inlining would produce ill-typed code, even tho it’d indeed work, isn’t it?
If that were allowed, the compiler would have to generate additional (unsafe) casts when inlining.
so I guess you can define an inline apply outside of the scope of Positive, with the unsafe casts.
If that’s what you want, in principle I agree that could be automated, but it doesn’t sound easy: it seems you’d need to replicate (a variant of) erasure during inlining. Except you’d need to produce casts that appease Scala’s typechecking.
Oron Port
@soronpo
I don't understand. The opaque Positive receives an Int. What does it matter if the definition is inlined?
Paolo G. Giarrusso
@Blaisorblade
say it’s inlined in a context where Positive and Int are unrelated.
now, the result of inlining doesn’t typecheck, does it?
however, in Dotty the result of each phase must typecheck, and that’s enforced by -Ycheck (unlike Scalac).
Paolo G. Giarrusso
@Blaisorblade
Anyway, I can see why you'd want this to be supported anyway, if you need to use dotty inlining for some reason (say performance, tho it seems JIT should handle this example). Feel free to make a feature request (not that I have a real say), it could well be much easier than I think.
jeremyrsmith
@jeremyrsmith
I dunno, I think source-level inlining of that particular case might be unnecessary if it’s intended as an optimization. It would be interesting to see a benchmark though. Since apply ought to end up as a very small static method over primitive ints, it seems like a rare case when the JVM shouldn’t have any trouble inlining that at runtime
I get that “the JVM will handle it!” is an oft-overused mantra though :grinning:
Paolo G. Giarrusso
@Blaisorblade
As said, yep; but the JVM doesn't handle all that we want.
Since the problems are usually with higher-order functions, maybe fold would be a better example. But I think you need an inner loop inside the fold to see the problem (like with map), so I still can't easily construct a realistic example.
Alexander Myltsev
@alexander-myltsev

hi

Dotty allows _.withDottyCompat(scalaVersion.value) to use Scala2 dependencies. I have Scala2 and Dotty projects in the same build file. what should I place for the dependsOnof Dotty project to correctly depend on Scala2 one?

Alexander Ioffe
@deusaquilus
Hi Guys, I’ve got a brief hit-and-run question. What’s the difference between inline def and inline val? I’m seeing places where the former works but not the latter.
Finn Hackett
@fhackett

@deusaquilus I think it's similar to plain def and val, in a way. val is evaluated once and stored, so inline val has to be able to pretend this at compile time. So, any code that does ... anything, really, does not work as the only way you can inline something while pretending it was only evaluated once is to know that it's some kind of constant. The current limitation is constant values as defined here: https://www.scala-lang.org/files/archive/spec/2.12/06-expressions.html#constant-expressions (link lifted from Dotty docs). def on the other hand is evaluated on demand. This means it doesn't really matter what the body of an inline def does since the compiler can just paste that code at the callsite and have the result act similar to a def call.

That's my intuition, anyway.

Alexander Ioffe
@deusaquilus
That makes sense. Thanks @fhackett
Katherine Prevost
@hypatian
Checking for certainty: With the new @main method model, there's no way to create a trait or class that will provide a main method to any object that extends it, since the compiler will not allow the @main annotation on non-statically-callable methods (even if a static instance of the class would cause the method to be available statically). Is that correct, or is there a technique that I've missed that could do this?
Paolo G. Giarrusso
@Blaisorblade
@hypatian you can still provide standard main methods, no?
docs are clear they're not somehow deprecated
Katherine Prevost
@hypatian
Oh. facepalm Yes, of course.
Walter Chang
@weihsiu
how to i write a function with signature like def [A, B, C](f: A => C) ~ (g: B => C): (A | B) => C ? i know ordinary matching will not work. do i need to resort to "scala.quoted.Type"? both A and B can be union types as well.
Lukas Rytz
@lrytz
quick question: wehre does TASTy go? when i run dotr C.scala, I get C.class with a TASTY classfile attribute, and i get C.tasty. The .tasty files also end up in jars. What does the attribute contain?
Katrix
@Katrix
Is there any reason why parameter untupling doesn't work for maps?
Guillaume Martres
@smarter
Some methods got overloaded in 2.13
Katrix
@Katrix
Is it considered a bug? Would be a shame if not, considering I feel mapping over maps was one of the big things I was looking forward to with that
Guillaume Martres
@smarter
Yes
Katrix
@Katrix
Is there already an issue for it, or should I create one?
Guillaume Martres
@smarter
Someone needs to fix untupling to deal with overloading
Don't think there's an issue
Travis Brown
@travisbrown
Is there documentation on how to publish Dotty locally for use in sbt projects? I have it working but not in a way that feels very natural.
(if I just publishLocal and change the sbt project to use the snapshot version, it expects dotty-sbt-bridge to be published with the -nonbootstrapped version suffix.)
Guillaume Martres
@smarter
@travisbrown dotty-bootstrapped/publishLocal
I really should just rewire publishLocal to do that by default
Travis Brown
@travisbrown
@smarter ah, thanks—I guessed there had to be something like that.
Guillaume Martres
@smarter
I'm very proud that all of dotty's bootstrapping magic is handled transparently by the sbt build :p
But publishing the non-bootstrapped compiler isn't really useful so that never did anything usable
som-snytt
@som-snytt
:+1: Thanks for the sbt magic on both scala 2 and 3 builds. It is amazing tech. Of course, any sufficiently advanced technology can make you forget that it's no longer 1999. I don't know what that means, besides let's party like it's that year.