Derivation of codecs with Dotty (Scala 3)
See original GitHub issueCurrently jsoniter-scala uses some features of experimental Scala 2 macros which are not ported to Scala 3. They are described in the following PR to the Scala Migration Guide.
Two possible solutions:
- Port
Evals.eval
to Scala 3 - Redesign jsoniter-scala-macros API to avoid usage of
Evals.eval
calls and refactor jsoniter-scala-core implementation to avoideval.eval
calls (see dependency onexpression-evaluator
).
Issue Analytics
- State:
- Created 5 years ago
- Reactions:18
- Comments:14 (8 by maintainers)
Top Results From Across the Web
Package structure - Scala 3 - EPFL
This is the documentation for the Scala standard library. · The scala package contains core types like Int , Float , Array or...
Read more >lampepfl/dotty - Gitter
I'm merely making a technical point about ScalaCheck and Dotty and how to ... work because there isn't yet a codec generator using...
Read more >Scodec for Scala 3 - Speaker Deck
Scala 3 introduces new features which help manage complexity. In this talk, we'll look at porting Scodec from Scala 2 to Scala 3, ......
Read more >Scodec for Scala 3 | SkillsCast | 22nd July 2020 - Skills Matter
Question: The casts in your codecs - do you think that scala 3 will ... Starting dotty REPL... scala> trait Semigroup[A] { |...
Read more >Type Class Derivation - Scala Documentation
Where of course TC and DerivingType are applied to types of the correct kind. To make this work, we split it into 3...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Here: https://github.com/rssh/jsoniter-scala/tree/scala3 is an attempt to port existing macros to scala3.
I make it compiled but not yet run. Note, that this attempt was porting with minimal changes, I have not tried to improve code organization.
Possible local next step – look at the first errors in the tests compilation logs
, extract this error into small reproducible examples and submit it to the dotty team or discover our own bug. repeat.
I think, porting existing code is possible but time-consuming [i.e. marathon, not sprint]. (I’m not sure that I can allocate an appropriate time budget for this, but maybe somebody can start from that point.
Only one thing, which is used in current macros and has no direct analog in dotty is access to the default values of primary constructors. (see https://github.com/lampepfl/dotty/discussions/14078 ), eventually, it is possible to extend the tasty reflection API.
Also, I’m not sure that the current approach is ideal – maybe better to write derivation from scratch, (not checked this, an idea to write all derivation inside some trait from which an instance of configuration is accessible). Differences are not very big, from the other side – code organization can be better) In case, if I have had enough time, I have started to explore this way.
In any case, It would be good to see branch ‘scala3-experiment’ here. (and maybe create a new subproject to explore dotty-only derivation)
@domdorn Yes, you can! It is available on the Maven Central. Please try and send your feedback.