Automatic `@as_record` pattern matching

[jariji]

Is there a risk of problems if structs are treated as @as_record by default? It would be more convenient and seems standard in other languages.

[Taine Zhao]

I have some to say in terms of this issue, so I divide them into the following 2 parts.

Replies

Is there a risk of problems if structs are treated as @as_record by default?

"No" for most pattern matching implementations: other Julia matching libraries, Python PEP 634, Rust, etc.

For MLStyle:

1. Currently, @as_record has a significant impact on pre-compilation time.
2. (See the reply to your next question)

It would be more convenient and seems standard in other languages.

This is quite right, but MLStyle was designed with "extensible matching" in mind. In fact, how patterns map to Julia code is fully controlled by the pattern_uncall method which allows further customization for user types. Such an implementation gives great extensibility, but in some degree makes it a bit difficult to make @as_record default using multiple dispatch.

Further Plan

MLStyle was a bit too extreme in terms of completeness and extensibility in the previous years, but it turns out that not all features are widely used, which is partially due to the poor promotion but also suffers from a disconnect with major/simple use cases.

I'm planning to rewrite MLStyle with only "pragmatic" features included, to promise

1. more common assumptions such as default @as_record and native support for Base.Enum
2. easier APIs for user-level extensibility.
3. lightning-fast import time and macro expansion time
4. performance improvements (for @noinline and @nospecialize argument)
5. native support for dependency free codegen (Roger-luo/Expronicon.jl#13)

Currently in the process of trying to organize some interested contributors;