Decide whether asm! and/or global_asm! should be exported from the prelude.

[bstrie]

In #84019 it was decided that asm! and global_asm! should be defined in core::arch rather than be defined in the crate root. Whereas anything defined in the crate root is essentially "in the prelude" by necessity, being defined elsewhere means that we have the option of deciding whether or not these macros should be exported from the prelude.

In the original Zulip thread regarding which module these macros should be defined in, there was a small amount of discussion as to whether or not these should additionally be exported from the prelude: https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/namespacing.20.60asm!.60/near/233407632 . There did not seem to be a clear prevailing opinion.

Furthermore, I faintly recall from the most recent libs-api meeting someone mentioning that adding new macros to the prelude (or even the crate root) might be a compatibility hazard, and should only be done during an edition. I'm not sure if this is an official policy or not.

Note that this is not a blocker for asm! stabilization, as the item can be stabilized at arch::asm and exported from the prelude any time in the future.

[m-ou-se]

The prelude should probably just contain things that are widely used. While asm!() has a pretty clear meaning, there's not going to be a lot of users.

However, @dtolnay mentioned that it might be good to have it in the prelude as a 'marketing' feature: People looking through the prelude documentation will discover the existence of inline assembly, showing that Rust is also a low level language.

On nightly, they're already in the prelude and seemingly not breaking anything, so that's not much of a concern.

Pinging @rust-lang/libs-api for more opinions.

[BurntSushi]

For me personally, it feels a little weird to put it in the prelude, especially if it's really just for marketing purposes. Inline assembly is a rarely used feature, so tucking it away into a module feels like the right thing to me.

Of course, making it easy to discover features is important too. My hope is that after inline assembly lands, doing a web search for "rust inline assembly" will (eventually) bring you to the right place. Maybe that's good enough?

[joshtriplett]

"marketing" is an interesting angle I hadn't considered.

Personally, I think these should be in the prelude for a different reason: to make them feel like innate language capabilities. You don't have to import a name from a module to use things like async and await, or closures, or (in the future) generators. I think inline assembly should feel the same way.

[thomcc]

My gut feeling is that inline assembly uses macro syntax might mean that it won't feel like an innate language capability even if it is in the prelude.

I think putting it in a module¹ is the right balance given how rarely it's used, and I say this as someone who uses it frequently, even in its current unstable state.

1: Well, fine so long as it's not a different module for each arch, which I believe is no longer being considered.

[Amanieu]

I feel ambivalent about this: I am probably one of the bigger users of asm! (78 uses over 10 files), but adding an import line for this is really very little effort that I don't mind it. In the end, I am happy with both options.

[npmccallum]

I'm a pretty big user of this (at least a few dozen invocations across a bunch of crates). I also don't mind an import line. I suspect that use of this feature is somewhat uncommon and I'd hate to litter the prelude for my minor inconvenience. Anyone who needs this feature knows they need it and can google it. I don't see a reason to advertise it.

I use TryFrom a lot more and it isn't (yet) in the prelude (this one does bug me...).

[thomcc]

adding an import line for this is really very little effort that I don't mind it.

Ultimately, the fact that you'll be able to use it as core::arch::asm! is why I don't mind. If it required a separate import line (the way traits do), I'd not be a fan. (That said, this would be terribly inconsistent with how other macros work, so I don't think anybody else would be either)

[joshtriplett]

On Fri, Aug 13, 2021 at 10:46:17AM -0700, Thom Chiovoloni wrote: Ultimately, the fact that you'll be able to use it as `core::arch::asm!` is why I don't mind.

That feels obtrusive in modules that use many, many asm blocks. That contributes to that feeling of "not a native Rust language feature" that I'd like to avoid. You don't have to include a specific header to use `__asm__` in C.

[BurntSushi]

@joshtriplett Could you say more about why you want it to feel like an innate language feature? Is it primarily because it feels that way in C?

[joshtriplett]

@BurntSushi Sure. Off the top of my head, trying to introspect on that feeling: I'm thinking about the mindset associated with one of the types of development that commonly invokes inline assembly: low-level OS/firmware/systems/etc programming. Much like many other compiler attributes that control binary sections, linker attributes, and similar, this feels like something that should have a direct straightforward meaning in code generation, with zero flexibility for the compiler. This is a "drop down to low-level assembly" mechanism, and it fits well into a mindset of thinking of all of your code in terms of the semantics of the underlying assembly.

In addition, assembly is a feature that fundamentally must integrate natively with the compiler's code generation, and can't be done purely using library mechanisms, because it has to handle things like clobbers, and arrange for the right inputs to be in the right registers. So it feels right for it to be built into the language. And something that's available via a specific library path doesn't feel like "part of the language".

(The other common case for inline assembly is optimization, for which I'd expect this to feel like less of an issue.)

[bstrie]

For people who would like to see asm in the prelude, what is your opinion on having global_asm in the prelude? Is only the former important enough to warrant it, or do you see them as a package deal?

(Also to reiterate, there is no urgency to this issue as it's not a blocker for stabilizing asm.)

[joshtriplett]

@bstrie I personally think the same logic applies to global_asm, and it's not like the name global_asm is likely to conflict with anything. I don't consider them a package deal, though, and I place more importance on having asm in the prelude.

[joshtriplett]

@rfcbot merge

In advance of the next time this gets discussed in a meeting, I'd like to use rfcbot to gauge consensus on keeping asm! (and global_asm!) in the prelude.

I personally believe they should be available without an import, to give them the appearance of a built-in language mechanism (which they inherently have to be).

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[workingjubilee]

From the perspective of someone who previously used Python, having to import to do IO, when Python has open as a builtin, feels odd. From the perspective of someone who previously used JavaScript, having even trivial math and logging functions be (somewhat) scoped feels normal, but the rules around strings, arrays, and Vecs get quite strange. Rust makes println! available in the prelude, even though its cousin requires #include <stdio.h> in C. All of these have caused me odd little impedances when context switching between each of these languages and Rust. I always get the C compiler to yell at me about using a function that's not declared, and I try looking in a library instead of the builtins for open(), and... you get the idea.

And for x86 assembly... For Rust, libcore is really required to make things "go", but the parts that are injected into the prelude are rather arbitrary, based largely on frequency of use. A rather lot of things in libcore degrade to intrinsics which wind up being pretty direct invocations to the compiler, yet not all such things in libcore are in the prelude. I do not see how asm! or global_asm! is truly different from the compiler intrinsic functions in core::arch, for example, most of which have a direct 1:1 lowering, and are functionally almost-equivalent to injecting the equivalent assembly, even linking against LLVM IR that is target-arch-scoped.

I do not have any fundamental objection, however, to choosing either way.

[mark-i-m]

I would also like to see asm! in the prelude. My "feeling" is similar to Josh's. As a low-level programmer, asm! is a fundamental low-level utility; I feel about asm! how others might feel about Vec or Option. Requiring a special import for asm! makes it feel like systems program is a second class concern for rust. I'm not sure if that's reasonable or not, but that's my gut reaction.

Also, the primary objection seems to be cluttering up the macro namespace, but I don't think I have ever seen another macro called asm! or global_asm! before, so I'm skeptical this should be a concern.

[BurntSushi]

I personally did not tick my box because I'm not really convinced at all that either of these macros should be in the prelude, now that we have the ability to namespace macros. I just do not think inline assembly is anywhere near common enough to be deserving of it. I do not think comparisons to Vec or Option are particularly good here, because the frequency of use across all domains is no where near the same.

I've stopped short of registering a blocking concern because I don't know that I feel strongly enough to go be a lone voice against this if everyone else wants it.

[workingjubilee]

I would also like to see asm! in the prelude. My "feeling" is similar to Josh's. As a low-level programmer, asm! is a fundamental low-level utility; I feel about asm! how others might feel about Vec or Option. Requiring a special import for asm! makes it feel like systems program is a second class concern for rust. I'm not sure if that's reasonable or not, but that's my gut reaction.

C requires #include <stdlib.h> for malloc and free, Rust does not for Vec.
Actually, now I do have an objection, and not just a comment:

All of these comparisons propose Rust should define itself in terms of other languages when it is not those languages.
However, if we wish to make Rust more like other languages, such as C, then I see no deep reason not to.
Let us drop std::vec::Vec from the prelude and namespace println! when we add asm!, so we can make Rust more like C.

[workingjubilee]

Less flippantly: "I feel so-and-so is very fundamental to my concerns" applies for every single function, type, and macro in std. Why not Error? Why not Arc, or Mutex, as those are very often used in multithreaded programming? That's something Rust is uniquely good at, why not market those? Sure, I guess we don't like our Mutex much. How about the Atomics instead?

All of the proposed Simd types and the existing std::arch compiler intrinsic functions certainly require a lot of compiler assistance, so they fill that criteria. And for the portable versions, it will be a distinct capability, too, not something all languages get as strong a hand in, so it's quite "marketable". And graphics programming and digital signal processing use SIMD a lot,

And it occurs to me that moving something into the prelude has a serious drawback that no one seems to have discussed:
It makes it much harder to figure out where it is coming from.

It's quite possible nothing as rare in use as asm! should be in the prelude's namespace, because then it will not be immediately obvious from the file and tracing it to that fateful use std::arch::asm; where it comes from, and thus which module to look in.

Rust is a programming language already used by millions. Even if we see a few familiar faces in these discussions again and again, the question should be what we want all Rust programmers to find easier, and what legacy we wish to leave for the next generation of programmers, which will be far more numerous.

I am not sure that introducing something into the prelude's namespace is not merely about convenience. I think it is expressing an expectation that Rust programmers know what it is and where they can find it if they need to read up on it. This is a mental toll on learning Rust, and the toll is already high, with understanding the semantics of Vec, String, Option, and Result, From and Into.

[mark-i-m]

I actually wish those things were in the prelude, along with all the collection types. Importing them feels like a completely unnecessary papercut to me. (I'm inclined to say that nearly everything in std should be in prelude, but I haven't thought through the implications enough to go that far).

I don't really feel that putting something in the prelude makes it harder to find because I almost always search rustdoc by the name of the item, not the module. I think it should be considered poor style to define a type with the same name as a std type.

[rfcbot]

The final comment period, with a disposition to postpone, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.