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

Rename macro_rules! to macro! #8224

Closed
bluss opened this issue Aug 2, 2013 · 14 comments
Closed

Rename macro_rules! to macro! #8224

bluss opened this issue Aug 2, 2013 · 14 comments
Labels
A-syntaxext Area: Syntax extensions

Comments

@bluss
Copy link
Member

bluss commented Aug 2, 2013

Use a shorter and easier to understand name for this oft-used syntax extension.

@glaebhoerl
Copy link
Contributor

What about define! to parallel C?

@Kimundi
Copy link
Member

Kimundi commented Aug 2, 2013

@glehel I think we don't want people to think that our macros work like C macros, so we might not wanna mirror that name.

@bluss
Copy link
Member Author

bluss commented Aug 2, 2013

To implement this change, is it possible to just add the macro syntax extension twice, once under the new name, and then migrate all instances after a snapshot?

@Aatch
Copy link
Contributor

Aatch commented Aug 3, 2013

@blake2-ppc it should be possible to do that, basically just register another syntax extension that goes to the same code.

Also, I'm nominating this for backwards compatible.

@bstrie
Copy link
Contributor

bstrie commented Aug 6, 2013

I believe that @paulstansifer and/or @jbclements specifically favored the macro_rules name for similarity with Scheme's syntax-rules construct. I personally wouldn't be opposed to the shorter name.

@bstrie
Copy link
Contributor

bstrie commented Aug 6, 2013

Though perhaps we could find a middle ground and rename macro_rules! to syntax!. This has the bonus effect of no longer misleading C programmers into thinking that our macros are textual, but it does risk confusion with syntax extensions.

@paulstansifer
Copy link
Contributor

Have we thought about what we will name the procedural-macro-generating construct, when that is implemented? If we have multiple ways of defining macros, it seems like it would be weird for only one of them to be called macro.

@jbclements
Copy link
Contributor

I have no dog in this fight; I'm not a strong defender of macro_rules!.

@bstrie
Copy link
Contributor

bstrie commented Aug 6, 2013

@paulstansifer What is this procedural-macro-generating construct you speak of?

@paulstansifer
Copy link
Contributor

@bstrie It doesn't exist, but the prevailing mood (as I understand it) is that it should exist, eventually.

@catamorphism
Copy link
Contributor

Leaving this up for debate. Macros are not in scope for 1.0, so de-milestoning

@nikomatsakis
Copy link
Contributor

I prefer the name macro!()

@huonw
Copy link
Member

huonw commented Mar 2, 2014

Triage: as @catamorphism says, no change, but not an 1.0 concern due to feature-gating.

I do agree with @paulstansifer though: calling this macro when there are possibilities of other macro-generating constructs (especially now that we have loadable syntax extensions: anyone can write a macro-making macro now).

@rust-highfive
Copy link
Collaborator

This issue has been moved to the RFCs repo: rust-lang/rfcs#293

flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 13, 2022
… r=llogiq

Fix `type_repetition_in_bounds`

fixes rust-lang#7360
fixes rust-lang#8162
fixes rust-lang#8056

changelog: Check for full equality in `type_repetition_in_bounds` rather than just equal hashes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-syntaxext Area: Syntax extensions
Projects
None yet
Development

No branches or pull requests