Review increasing number of code generation use cases to understand potential missing capabilities of the language

[idkq]

Questions

• Is it a goal to offer capabilities to reduce code generation and is there any review process to understand why and maybe map them out?
• Or it is an inherit style of the language, and if so, should we look at way to better couple it with the core language instead of running a separate process?
• Should we list we cases that currently require code generation and see what is missing in terms of language features? I'm not aware of another language with such a heavy use of code generation.
• Any appetite for preprocessor directives like? Or anything that runs before compiling

Deliverable

A list of use cases of code generation and how other languages tackle the problem.

[munificent]

Is it a goal to offer capabilities to reduce code generation and is there any review process to understand why and maybe map them out?

Yes! We are looking into static metaprogramming features this year. No promises or detailed designs yet, but it's a priority.

Should we list we cases that currently require code generation and see what is missing in terms of language features? I'm not aware of another language with such a heavy use of code generation.

We have collected quite a few use cases already but we're always happy to have more, yes.

[idkq]

This is great news! I’m sure people will love this.

Not knowing which use cases you have makes a bit difficult to suggest. But one that comes to mind is adding fromMap toMap methods in class models for serialization. How to solve for that.

I’ll try to add more.

[Levi-Lesches]

Here's a few, although it's been included in many discussions already (namely #1482):

1. toJson() and fromJson
2. Basic dataclass methods: toString(), ==, hashCode, and copyWith()
3. A macro to convert a Widget Function([BuildContext context]) -> StatelessWidget with fields copied from the original functions parameter list.
4. A dispose override on States that auto-dispose of disposable fields

[esDotDev]

Some reference packages for the above:

1. https://pub.dev/packages/built_value_generator
2. https://pub.dev/packages/freezed
3. https://pub.dev/packages/functional_widget

Going through pub.dev, there's a couple other code processing categories that look popular:

• Mock Class generators (https://pub.dev/packages/mockito, https://pub.dev/packages/mocktail)
• Architecture generators (https://pub.dev/packages/mobx_codegen, https://pub.dev/packages/auto_route)

The other popular packages are usually processing some external asset, like language jsons or svg files.

[cedvdb]

We have collected quite a few use cases already but we're always happy to have more, yes.

@munificent
Is it a possibility to have a data class before static meta programing ? That would tighten the scope and cover a lot of requirements already. Maybe that can go hand in hand with the Record proposal ? A Record could be made serializable. A class that extends record that is.

[Levi-Lesches]

Is it a possibility to have a data class before static meta programing? That would tighten the scope.

I don't know about the plans for implementing records but I proposed an implementation/syntax for metaprogramming at #1565 and while it would be a pretty big change to restrict it to just one specific use-case, I don't think it would be such a major change in general. It's based on writing Strings into Dart files with code. I included an example of dataclasses in there, feel free to check it out.

[cedvdb]

I'm specifically talking about data class without static metaprogramming as the scope of metaprogramming is bigger and the more example I see of it, the less I see advantages over a tool that would do such things like a built_values package (which I don't use, because I don't like writing code like that).

[Levi-Lesches]

The advantage is that there are currently a lot of proposals for small features like records, StatelessWidgets from functions, enum maps (#1511), JSON serialization, etc (all of which I fully support). As you may have noticed, 2 of those have already been implemented by code generation. By investing time in metaprogramming, we can hit all of these at once, while allowing the Dart community to make simple packages that are easy to use.

[cedvdb]

The advantage is that there are currently a lot of proposals for small features like records, StatelessWidgets from functions, enum maps (#1511), JSON serialization, etc (all of which I fully support). As you may have noticed, 2 of those have already been implemented by code generation. By investing time in metaprogramming, we can hit all of these at once, while allowing the Dart community to make simple packages that are easy to use.

That would be already possible with a build runner it doesn't happen at compile time and you have to type extras but its possible. In all honesty, the more example I see, the more I understand a comment I originally downvoted that said that this would make code less readable.

[munificent]

Is it a possibility to have a data class before static meta programing ?

It's a possibility, but my hope is that we can design a sufficiently expressive static metaprogramming system that "data classes" could be implemented at the library level using it. Kotlin-style data classes are basically taking a somewhat arbitrary set of policies (immutability, copying, value equality, etc.) and baking them into the language.

The problem is that policy preferences change more rapidly than languages. A few years from now when users decide that instead of immutable value types they want persistent data structures, we can end up with essentially deadweight language features like XML literals in Scala.

[cedvdb]

The problem is that policy preferences change more rapidly than languages. A few years from now when users decide that instead of immutable value types they want persistent data structures, we can end up with essentially deadweight language features like XML literals in Scala.

Is that a certainty though ? javascript serialization is easy to use and no one bothered changing that. Furthermore having to maintain toString, copyWith and serialization is already out of date. I agree that meta programing would solve the issue but I hope the team is going to be careful onto what problems it needs to solve and what the language itself needs to solve. I feel like it can get ugly fast.

You know better than me, but it makes me a bit uneasy. I just want to counter weight the hype

[munificent]

javascript serialization is easy to use and no one bothered changing that.

I mean, we definitely have users using protobufs, Flatpack, and plenty of other serialization formats too.