Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Where should we put macros? #351

Open
ghost opened this issue Oct 16, 2019 · 1 comment
Open

Where should we put macros? #351

ghost opened this issue Oct 16, 2019 · 1 comment
Labels
api design Open design questions feedback wanted Needs feedback from users question/feedback A question or user feedback

Comments

@ghost
Copy link

ghost commented Oct 16, 2019

Consider the following macros:

  • async_std::task_local
  • async_std::println
  • async_std::task::ready

They are not organized in a very sensible way. Why would task_local be in the root module and not in the task module? And why is println not in the io module if standard I/O functionality lives there?

In the Rust standard library, all macros live in the root module. This is perhaps a historical artifact because macros couldn't be placed anywhere else until Rust 2018 (remember the age of #[macro_use]?). If the standard library was designed today, perhaps we'd have std::io::println instead of std::println.

So we're facing a dilemma: do we organize our macros in async_std more logically (unlike std) or just dump them all in the root module (like std)? Or, do we keep the current situation and have equivalents of macros from std in the root module and place other macros elsewhere?

Macros in the root module are also re-exported in the prelude (just like in std). However, other macros aren't.

Opinions?

@ghost ghost added api design Open design questions feedback wanted Needs feedback from users question/feedback A question or user feedback labels Oct 16, 2019
@yoshuawuyts
Copy link
Contributor

@stjepang I'm thinking we re-export the std counterparts as part of the root of the crate. But then we also export the individual macros from their respective submodules.

Probably the odd macro odd out here is write / writeln which makes sense to have both part of io and fmt. We don't have a fmt crate currently so it's not a problem, but yeah still.

Related PR: #328

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api design Open design questions feedback wanted Needs feedback from users question/feedback A question or user feedback
Projects
None yet
Development

No branches or pull requests

1 participant