stackabletech / stackabletech/operator-rs

stackable-versioned: Require inner module definitions to have the same visibility as the parent

Open
#1,028 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
167
Forks
19
Avg merge
1d 6h
Merged PRs (30d)
9

Description

As discussion with @Techassi, we should warn/error if the visibility of the inner module doesn't match the outer module.

The inner module ends up with the same visibility as the parent anyway, but it is confusing if it is not the same.

#[versioned(version(name = "v1alpha1"))]
pub mod versioned {

    // contents of this mod get merged with the generated `v1alpha` mod.
    // nothing unusual here, pub all the way
	pub mod v1alpha1 {
        pub use v1alpha1_impl::Error;
    }

}

Is equivalent to:

#[versioned(version(name = "v1alpha1"))]
pub mod versioned {

    // contents of this mod get merged with the generated `v1alpha` mod, 
    // with `pub` visibility (because of `pub mod versioned`).
    // 👇
	mod v1alpha1 {
        pub use v1alpha1_impl::Error;
    }

}

However, it appears confusing to the reader. Eg:

How can the pub use be of any use inside a private mod?

... with the answer being oh, the mod is actually pub mod because of pub mod versioned which leads to pub mod v1alpha being generated, which absorbs the contents of the mod v1alpha1 that you see in the source.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the stackable-versioned implementation that processes the outer and inner module definitions. Add validation so mismatched visibility produces a warning or error, then verify the behavior against the nested module examples described in the issue.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
tooling
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.