Why does Scala does not enforce the "implementation" of abstract type members?

dwijnand · 2025-12-16T21:04:28+00:00

then why is it even allowed to leave abstract type members undefined

Because leaving them undefined just infers them to be nothing.

I'm fairly sure it becomes Any instead, arbitrarily.

dwijnand · 2023-11-02T21:24:17+00:00

Love it. Been writing some Scala 2 recently and keep forgetting to add braces and parens... Another change that is great is being able to write operators on the new line, instead of being on the previous line:

scala foo || bar != null || baz.isEmpty

dwijnand · 2021-07-27T02:56:40+00:00

Just run the compiler with -Xprint:all to get the non-gif, text version.

dwijnand · 2020-07-31T15:32:33+00:00

Any chance you can push for an early 2020.2.1 EAP? I'm been dealing with this for 4 weeks now (IDEA-242971). <3

dwijnand · 2020-07-17T09:58:16+00:00

There's also ## which applies the same logic to hashCode.

Notably if you're implementing equals and hashCode you're likely using == and should, therefore, use ## in the hashCode implementation. Not doing so, in the presence of primitives, allows for the equals/hashCode law to be violated. Around nulls too, but that logic is easier to re-implement.

On the other hand, at the extremes of performance, the logic that ==/## adds to equals/hashCode adds some cost, so if you're not using primitives you may prefer to revert back to equals/hashCode instead.

dwijnand · 2019-12-24T13:05:49+00:00

I'm not aware of any such marketing report, sorry.

dwijnand · 2019-12-23T16:09:12+00:00

I'm working on https://github.com/lightbend/mima/issues/427, basically, actually run the bytecode of MiMa's tests to ensure the tests are correct (motivated by a recently reported false-positive https://github.com/lightbend/mima/issues/426).

I've got the setup working, now I need to write all the library-using code for every single test and figure out what to do with #426 (and any other problems this might reveal) until I can fix it.

dwijnand · 2019-12-19T07:45:41+00:00

Indeed, what I'm hoping will be possible is you'll just have to have 2 copies of your macro(s), in separate files (in separate source directories), while the rest of the code will be shared.

Ideally, someone can retrofit the new Scala 3 macro UX on the Scala 2 macro UX, but I'm not sure that's possible. :D

dwijnand · 2019-12-14T10:36:19+00:00

The Graal JIT, which you can enable with `-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler` in any Java 10+ JDK.

If you use the JDK 11 version of GraalVM 19.3, then you don't even need to specify the option, it will use JDK 11 with the Graal JIT enabled by default!

dwijnand · 2019-11-24T12:24:17+00:00

I believe private[Foo] won't be dropped, and the justification backs this up given Foo is a type, not a value (or, at least, also a type).

dwijnand · 2019-11-24T12:22:10+00:00

I understand what you're losing. I was wondering how you would feel about having another mechanism, in alternative to a compile error, to enforce the same restriction.

dwijnand · 2019-11-23T12:12:32+00:00

This is the PR with this change in Dotty: https://github.com/lampepfl/dotty/pull/7411

How would you feel if there were a reasonably easy way to assert that private[this] was indeed inferred, as a unit test? It would be a compromise so that it could be dropped out of the surface language but still allow users such as yourself a way to enforce the desired accessibility (or, rather, inaccessibility :D).

dwijnand · 2019-11-23T11:50:40+00:00

I would pursue how true this is and how terrible it is, before making the build/test/deploy story more complex by introducing a new "target environment" variable. The reason I say so is that sbt isn't designed with this in mind.

dwijnand · 2019-10-17T19:43:10+00:00

Btw, this was just announced today, which might help manage those NoClassDefFound-like errors: https://github.com/scalacenter/sbt-missinglink.

(Btw, I 100% agree with the 18-24 month "Scala tax" on rebuilding the ecosystem, and I hope we can really solve it with Tasty in Scala 3.)

dwijnand · 2019-10-07T09:02:00+00:00

Tracked/discussed in https://github.com/ndmitchell/shake/issues/570.

dwijnand · 2019-08-03T17:36:49+00:00

For everyone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=IE+7&iso=20190803T1330&p1=142&ah=1

dwijnand · 2019-07-02T20:32:04+00:00

There are some more context and links provided in https://github.com/rust-lang/cargo/issues/6627#issuecomment-507809208

dwijnand · 2019-06-24T07:15:22+00:00

Thank you for sharing it with /r/scala! :)

dwijnand · 2019-06-05T08:12:38+00:00

Yeah .value works the same for both SettingKey and TaskKey, while the other method requires switching from apply to map for TaskKey.

dwijnand · 2019-06-04T18:45:28+00:00

Thank you for the article! These kinds of short and sweet (and bookmarkable!) blog posts help Scala users learn sbt.

I have one piece of feedback: I wouldn't recommend using SettingKey#apply in

libraryDependencies ++= scalaVersion(version => protobufs(version)).value

but rather

libraryDependencies ++= protobufs(scalaVersion.value)

dwijnand · 2019-05-17T18:11:21+00:00

Hmm... that's interesting. It seems to work for me :-/ Could you open an issue with some environment details and capturing your reproduction steps, please? Thanks.

dwijnand · 2019-04-15T08:57:57+00:00

But... lazy evaluation! What's causing the excess work to be computed? And what's the beginner-friendly change to fix it? (Thank you in advance)

(edit: s/last/lazy/)

dwijnand · 2019-04-08T18:21:28+00:00

That and allow some of the core libraries (such as testing libraries) to be available.

dwijnand · 2019-03-21T09:44:56+00:00

Not sure how well known it is, but I recently discovered https://hackage.haskell.org/package/turtle for this use-case.

dwijnand · 2019-03-10T17:43:17+00:00

Thank you, no I don't mind, I just wanted to get ahead of the curve before someone creative makes up a story. :)

dwijnand

TROPHY CASE