Is this project dead? #147

mahkoh commented 2024年11月14日 12:59:54 +01:00

The last released version is 3.0-beta which adds value by allowing to write code that is generic over enums. However, this release is a year old. Could you confirm that there is currently no concrete effort to release these features?

The last released version is 3.0-beta which adds value by allowing to write code that is generic over enums. However, this release is a year old. Could you confirm that there is currently no concrete effort to release these features?

sugar700 commented 2024年11月15日 12:01:00 +01:00

Mostly, yes. At this point all that will likely be fixed is security issues or issues affecting compilation (in case enum-map gets broken by future Rust release), at this point I don't really want to maintain this project anymore.

Mostly, yes. At this point all that will likely be fixed is security issues or issues affecting compilation (in case enum-map gets broken by future Rust release), at this point I don't really want to maintain this project anymore.

Fuuzetsu commented 2024年11月18日 07:35:39 +01:00

We use enum-map extensively. I can take over the project either fully or as a co-maintainer if there's no plan to accept non-critical pull requests and releases.

EDIT: Or possibly we (https://github.com/tsurucapital/) would take it over as an organisation.

We use enum-map extensively. I can take over the project either fully or as a co-maintainer if there's no plan to accept non-critical pull requests and releases. EDIT: Or possibly we (https://github.com/tsurucapital/) would take it over as an organisation.

mahkoh commented 2024年11月21日 12:22:01 +01:00

I've gone ahead and written a replacement for my usecases: https://docs.rs/linearize

I also took the opportunity to fix some of the remaining issues with enum-map:

• The traits of the map, e.g. Clone, only depend on the the key and value type. In enum-map, some of these traits depend on the opaque K::Array type that is unknowable in code that is generic over K.
• In order to do this for Copy, I had to split the map type into two, StaticMap and StaticCopyMap, where StaticCopyMap only works for copyable values and is itself always copy. There are zero-cost conversions between these two types.
• The macro to create maps also works in constants and statics and works with single-use (non copyable/movable) values.
• Code generation of the proc macro is improved. The enum-map proc macro would generate code that used an amount of stack space that was linear in the number of variants (in debug builds) and did not always optimize to a no-op in the case of C-style enums. At least for C style enums, my macro always only uses a few bytes of stack space, complies to a lookup table in debug builds, and compiles to a no-op in release builds (tested for up to 10000 variants).

I've gone ahead and written a replacement for my usecases: https://docs.rs/linearize I also took the opportunity to fix some of the remaining issues with enum-map: - The traits of the map, e.g. Clone, only depend on the the key and value type. In enum-map, some of these traits depend on the opaque K::Array type that is unknowable in code that is generic over K. - In order to do this for `Copy`, I had to split the map type into two, StaticMap and StaticCopyMap, where StaticCopyMap only works for copyable values and is itself always copy. There are zero-cost conversions between these two types. - The macro to create maps also works in constants and statics and works with single-use (non copyable/movable) values. - Code generation of the proc macro is improved. The enum-map proc macro would generate code that used an amount of stack space that was linear in the number of variants (in debug builds) and did not always optimize to a no-op in the case of C-style enums. At least for C style enums, my macro always only uses a few bytes of stack space, complies to a lookup table in debug builds, and compiles to a no-op in release builds (tested for up to 10000 variants).

larseggert commented 2025年09月03日 08:37:55 +02:00

Has someone taken this over? It's great that https://docs.rs/linearize exists, but we'd rather see a fixed enum-map that retains the current API.

@martinthomson submitted some PRs that fix things which we'd like to see merged.

Has someone taken this over? It's great that https://docs.rs/linearize exists, but we'd rather see a fixed `enum-map` that retains the current API. @martinthomson submitted some PRs that fix things which we'd like to see merged.

sugar700 commented 2025年09月03日 09:09:10 +02:00

Right, those pull requests wait for CI to pass. Will merge them once they rebase, and I will try to release a new version of the library.

Right, those pull requests wait for CI to pass. Will merge them once they rebase, and I will try to release a new version of the library.