Skip to content

feat: implement proc macros for domain trait delegation#43

Open
arjo129 wants to merge 4 commits into
mainfrom
arjoc/feat/domains
Open

feat: implement proc macros for domain trait delegation#43
arjo129 wants to merge 4 commits into
mainfrom
arjoc/feat/domains

Conversation

@arjo129

@arjo129 arjo129 commented May 6, 2026

Copy link
Copy Markdown
Member

New feature implementation

Implemented feature

Proc macros for domain trait delegation

Implementation description

This commit introduces the mapf-derive crate which provides the #[derive(Domain)] macro. This macro allows for a more ergonomic and readable way to define domains by aggregating core traits (Activity, Weighted, Informed, etc.) through struct field delegation.

Examples have been added to demonstrate usage with basic traits and the AStar planner.

GenAI Use

We follow OSRA's policy on GenAI tools

  • I used a GenAI tool in this PR.
  • I did not use GenAI

Generated-by: Gemini CLI

This commit introduces the mapf-derive crate which provides the
#[derive(Domain)] macro. This macro allows for a more ergonomic
and readable way to define domains by aggregating core traits
(Activity, Weighted, Informed, etc.) through struct field delegation.

Examples have been added to demonstrate usage with basic traits
and the AStar planner.

Assisted-by: Gemini CLI
Signed-off-by: Arjo Chakravarty <arjoc@intrinsic.ai>
@mxgrey mxgrey added this to PMC Board May 6, 2026
@github-project-automation github-project-automation Bot moved this to Inbox in PMC Board May 6, 2026
arjo129 added 3 commits May 6, 2026 07:54
Signed-off-by: Arjo Chakravarty <arjoc@intrinsic.ai>
Signed-off-by: Arjo Chakravarty <arjoc@intrinsic.ai>
Signed-off-by: Arjo Chakravarty <arjoc@intrinsic.ai>
@arjo129 arjo129 marked this pull request as ready for review May 6, 2026 09:50
@mxgrey mxgrey self-requested a review May 19, 2026 01:13
@mxgrey mxgrey moved this from Inbox to In Review in PMC Board May 19, 2026
Comment on lines +38 to +42
#[weighted]
cost: ConstantCost,

#[informed]
heuristic: ManhattanHeuristic,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that these attribute names are just reflecting the trait names that they represent, but it feels a bit stilted to me. Would it be too confusing if we used attributes names like #[weight] and #[heuristic] to map to the appropriate traits? I'd be open to renaming the traits to correspond (e.g. Weight and Heuristic).

/// Define a domain using the new derive macro.
/// Adding Clone to GridDomain because AStar<D> needs to be Clone for the planner.
#[derive(Domain, Clone)]
#[domain(state = Point, error = NoError)]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would you think of also adding action = _ here? We would tweak the Activity trait like

pub trait Activity<State, Action> {
}

and we would remove the type Action associated type from Activity.

Comment thread mapf/src/lib.rs
Comment on lines +43 to +45
pub use super::algorithm::{self, *};

pub use super::domain::{self, *};

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't think of why we need the algorithm and domain module names inside the prelude.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: In Review

Development

Successfully merging this pull request may close these issues.

2 participants