[{"data":1,"prerenderedAt":1944},["ShallowReactive",2],{"page-\u002Frust\u002F20-modules-and-crates":3},{"id":4,"title":5,"body":6,"description":1898,"extension":1938,"meta":1939,"navigation":34,"path":1940,"seo":1941,"stem":1942,"__hash__":1943},"content\u002Frust\u002F20-modules-and-crates.md","20 — Modules & Crates",{"type":7,"value":8,"toc":1897},"minimark",[9,13,94,149,227,326,427,540,627,701,806,887,968,1091,1205,1315,1388,1453,1544,1647,1728],[10,11,5],"h1",{"id":12},"_20-modules-crates",[14,15,16,21,63],"question-wrapper",{},[17,18,20],"h3",{"id":19},"q1-what-is-the-default-visibility-of-an-item-function-struct-module-declared-inside-a-rust-module-with-no-visibility-modifier","Q1. What is the default visibility of an item (function, struct, module) declared inside a Rust module with no visibility modifier?",[22,23,26,42,51,57],"ul",{"className":24},[25],"contains-task-list",[27,28,31,36,37,41],"li",{"className":29},[30],"task-list-item",[32,33],"input",{"disabled":34,"type":35},true,"checkbox"," ",[38,39,40],"code",{},"pub"," — visible everywhere, including other crates",[27,43,45,36,47,50],{"className":44},[30],[32,46],{"disabled":34,"type":35},[38,48,49],{},"pub(crate)"," — visible anywhere in the current crate",[27,52,54,56],{"className":53},[30],[32,55],{"disabled":34,"type":35}," Private — visible only in the defining module and its descendant modules",[27,58,60,62],{"className":59},[30],[32,61],{"disabled":34,"type":35}," Private — visible only within the exact same file",[64,65,66,70,78],"details",{},[67,68,69],"summary",{},"Show Answer",[71,72,73,77],"p",{},[74,75,76],"strong",{},"Answer:"," C — Private — visible only in the defining module and its descendant modules",[71,79,80,83,84,86,87,89,90,93],{},[74,81,82],{},"Explanation:"," Rust's default visibility is private, but \"private\" means \"visible within this module and everything nested inside it,\" not \"visible only in this file.\" An item with no modifier is invisible to sibling or parent modules, and completely invisible outside the crate, ruling out A (which describes ",[38,85,40],{},") and B (which describes ",[38,88,49],{},"). D is the common misconception — file boundaries and module boundaries aren't the same thing, and a child module declared via ",[38,91,92],{},"mod"," (even in a separate file) still counts as \"inside\" its parent for privacy purposes.",[14,95,96,103,130],{},[17,97,99,100,102],{"id":98},"q2-what-does-pubcrate-mean-when-applied-to-a-function","Q2. What does ",[38,101,49],{}," mean when applied to a function?",[22,104,106,112,118,124],{"className":105},[25],[27,107,109,111],{"className":108},[30],[32,110],{"disabled":34,"type":35}," The function is visible only within the module it's declared in",[27,113,115,117],{"className":114},[30],[32,116],{"disabled":34,"type":35}," The function is visible anywhere inside the current crate, but not to external crates that depend on this one",[27,119,121,123],{"className":120},[30],[32,122],{"disabled":34,"type":35}," The function is visible to external crates but not within the current crate",[27,125,127,129],{"className":126},[30],[32,128],{"disabled":34,"type":35}," The function is exported only when the crate is compiled as a library",[64,131,132,134,139],{},[67,133,69],{},[71,135,136,138],{},[74,137,76],{}," B — The function is visible anywhere inside the current crate, but not to external crates that depend on this one",[71,140,141,36,143,145,146,148],{},[74,142,82],{},[38,144,49],{}," is a restricted-visibility modifier: it opens the item up crate-wide (any module in the same crate can call it) while still hiding it from downstream crates that use this one as a dependency — useful for internal helpers shared across modules without committing them to the public API. A undersells it (that's closer to fully private); C has it backwards; D confuses visibility with crate type (",[38,147,49],{}," behaves the same whether the crate is a binary or library, it just controls in-crate reach).",[14,150,151,155,190],{},[17,152,154],{"id":153},"q3-in-a-typical-binary-crate-which-file-is-the-crate-root-that-the-compiler-starts-building-from","Q3. In a typical binary crate, which file is the crate root that the compiler starts building from?",[22,156,158,166,174,182],{"className":157},[25],[27,159,161,36,163],{"className":160},[30],[32,162],{"disabled":34,"type":35},[38,164,165],{},"lib.rs",[27,167,169,36,171],{"className":168},[30],[32,170],{"disabled":34,"type":35},[38,172,173],{},"mod.rs",[27,175,177,36,179],{"className":176},[30],[32,178],{"disabled":34,"type":35},[38,180,181],{},"main.rs",[27,183,185,36,187],{"className":184},[30],[32,186],{"disabled":34,"type":35},[38,188,189],{},"Cargo.toml",[64,191,192,194,201],{},[67,193,69],{},[71,195,196,198,199],{},[74,197,76],{}," C — ",[38,200,181],{},[71,202,203,205,206,209,210,212,213,215,216,220,221,223,224,226],{},[74,204,82],{}," For a binary crate, ",[38,207,208],{},"src\u002Fmain.rs"," is the crate root — the module tree is built starting from the ",[38,211,92],{}," declarations in that file. ",[38,214,165],{}," (A) is the equivalent root for a ",[217,218,219],"em",{},"library"," crate (a package can have both, producing both a binary and a library target). ",[38,222,173],{}," (B) is a filename convention for a submodule's contents, not a crate root. ",[38,225,189],{}," (D) is the package manifest — it configures the build but contains no Rust code or module declarations itself.",[14,228,229,240,280],{},[17,230,232,233,235,236,239],{"id":231},"q4-given-srcmainrs-contains-mod-network-which-file-layouts-are-valid-ways-to-provide-that-modules-contents-rust-2018","Q4. Given ",[38,234,208],{}," contains ",[38,237,238],{},"mod network;",", which file layouts are valid ways to provide that module's contents (Rust 2018+)?",[22,241,243,252,260,272],{"className":242},[25],[27,244,246,248,249],{"className":245},[30],[32,247],{"disabled":34,"type":35}," Only ",[38,250,251],{},"src\u002Fnetwork.rs",[27,253,255,248,257],{"className":254},[30],[32,256],{"disabled":34,"type":35},[38,258,259],{},"src\u002Fnetwork\u002Fmod.rs",[27,261,263,265,266,268,269,271],{"className":262},[30],[32,264],{"disabled":34,"type":35}," Either ",[38,267,251],{},", or ",[38,270,259],{}," — both are recognized, though mixing conventions within one project is discouraged",[27,273,275,36,277],{"className":274},[30],[32,276],{"disabled":34,"type":35},[38,278,279],{},"src\u002Fmod\u002Fnetwork.rs",[64,281,282,284,293],{},[67,283,69],{},[71,285,286,288,289,268,291,271],{},[74,287,76],{}," C — Either ",[38,290,251],{},[38,292,259],{},[71,294,295,297,298,300,301,303,304,307,308,311,312,314,315,317,318,321,322,325],{},[74,296,82],{}," The compiler accepts two layouts for a module declared with ",[38,299,238],{},": the flat ",[38,302,251],{}," (the modern, 2018-edition-encouraged style, needed if ",[38,305,306],{},"network"," itself has submodules living in a ",[38,309,310],{},"src\u002Fnetwork\u002F"," directory), or the older ",[38,313,259],{}," style inherited from Rust 2015. A and B are each only half the truth — both forms genuinely work. D is not a recognized layout at all; ",[38,316,173],{}," must live ",[217,319,320],{},"inside"," a directory named after the module, not inside a literal ",[38,323,324],{},"mod\u002F"," directory.",[14,327,328,336,375],{},[17,329,331,332,335],{"id":330},"q5-what-does-use-crateutilsparse-do","Q5. What does ",[38,333,334],{},"use crate::utils::parse;"," do?",[22,337,339,348,357,366],{"className":338},[25],[27,340,342,344,345],{"className":341},[30],[32,343],{"disabled":34,"type":35}," Declares a new module named ",[38,346,347],{},"parse",[27,349,351,353,354,356],{"className":350},[30],[32,352],{"disabled":34,"type":35}," Brings the ",[38,355,347],{}," item, referenced by its absolute path from the crate root, into scope under a short local name",[27,358,360,362,363,365],{"className":359},[30],[32,361],{"disabled":34,"type":35}," Makes ",[38,364,347],{}," public to other crates",[27,367,369,371,372,374],{"className":368},[30],[32,370],{"disabled":34,"type":35}," Re-exports ",[38,373,347],{}," so downstream crates can import it via this path",[64,376,377,379,386],{},[67,378,69],{},[71,380,381,383,384,356],{},[74,382,76],{}," B — Brings the ",[38,385,347],{},[71,387,388,36,390,393,394,397,398,400,401,403,404,406,407,409,410,412,413,415,416,418,419,422,423,426],{},[74,389,82],{},[38,391,392],{},"use"," is purely a local scoping\u002Faliasing tool: ",[38,395,396],{},"crate::utils::parse"," is an absolute path starting from the crate root, and the ",[38,399,392],{}," statement lets the current file refer to that item as just ",[38,402,347],{}," instead of writing the full path every time. It does not declare anything new (rules out A — ",[38,405,92],{}," does that), does not change any item's visibility (rules out C — visibility is set at the item's definition with ",[38,408,40],{},"\u002F",[38,411,49],{},"\u002Fetc.), and a plain ",[38,414,392],{}," (without ",[38,417,40],{},") is not visible to code importing ",[217,420,421],{},"this"," module, so it does not re-export anything (rules out D — that requires ",[38,424,425],{},"pub use",").",[14,428,429,437,487],{},[17,430,432,433,436],{"id":431},"q6-what-is-the-purpose-of-pub-use-innerthing-written-in-a-parent-module","Q6. What is the purpose of ",[38,434,435],{},"pub use inner::Thing;"," written in a parent module?",[22,438,440,454,467,478],{"className":439},[25],[27,441,443,445,446,449,450,453],{"className":442},[30],[32,444],{"disabled":34,"type":35}," It moves ",[38,447,448],{},"Thing"," out of ",[38,451,452],{},"inner"," into the parent module",[27,455,457,459,460,462,463,466],{"className":456},[30],[32,458],{"disabled":34,"type":35}," It re-exports ",[38,461,448],{},", making it accessible via the parent module's path (e.g. ",[38,464,465],{},"crate::Thing",") in addition to its original path, without duplicating the definition",[27,468,470,472,473,475,476],{"className":469},[30],[32,471],{"disabled":34,"type":35}," It is a syntax error — ",[38,474,392],{}," cannot be combined with ",[38,477,40],{},[27,479,481,483,484,486],{"className":480},[30],[32,482],{"disabled":34,"type":35}," It makes ",[38,485,452],{}," itself public",[64,488,489,491,500],{},[67,490,69],{},[71,492,493,495,496,462,498,466],{},[74,494,76],{}," B — It re-exports ",[38,497,448],{},[38,499,465],{},[71,501,502,36,504,506,507,510,511,513,514,517,518,521,522,524,525,527,528,530,531,533,534,536,537,539],{},[74,503,82],{},[38,505,425],{}," is Rust's re-export mechanism: it takes an item visible at this point and makes it visible under a ",[217,508,509],{},"new"," public path too, letting library authors flatten a deep internal module tree into a clean public API (e.g. ",[38,512,435],{}," at the crate root lets consumers write ",[38,515,516],{},"my_crate::Thing"," instead of ",[38,519,520],{},"my_crate::inner::Thing","). ",[38,523,448],{}," still physically lives in ",[38,526,452],{},"; nothing is moved (rules out A) or duplicated. ",[38,529,425],{}," is valid, common syntax (rules out C). Re-exporting ",[38,532,448],{}," says nothing about ",[38,535,452],{},"'s own visibility — ",[38,538,452],{}," can remain a private module while one specific item from it is re-exported (rules out D).",[14,541,542,554,593],{},[17,543,545,546,549,550,553],{"id":544},"q7-given-pub-struct-config-pub-name-string-version-u32-what-is-true-about-a-caller-outside-the-module-accessing-configversion","Q7. Given ",[38,547,548],{},"pub struct Config { pub name: String, version: u32 }",", what is true about a caller outside the module accessing ",[38,551,552],{},"config.version","?",[22,555,557,569,581,587],{"className":556},[25],[27,558,560,562,563,565,566,568],{"className":559},[30],[32,561],{"disabled":34,"type":35}," It compiles — marking the struct ",[38,564,40],{}," makes all its fields ",[38,567,40],{}," too",[27,570,572,574,575,578,579],{"className":571},[30],[32,573],{"disabled":34,"type":35}," It fails to compile — ",[38,576,577],{},"version"," has no visibility modifier, so it defaults to private even though the struct itself is ",[38,580,40],{},[27,582,584,586],{"className":583},[30],[32,585],{"disabled":34,"type":35}," It compiles only if the caller is in the same crate",[27,588,590,592],{"className":589},[30],[32,591],{"disabled":34,"type":35}," It compiles, but emits a deprecation warning",[64,594,595,597,606],{},[67,596,69],{},[71,598,599,601,602,578,604],{},[74,600,76],{}," B — It fails to compile — ",[38,603,577],{},[38,605,40],{},[71,607,608,610,611,613,614,617,618,620,621,623,624,626],{},[74,609,82],{}," Struct visibility and field visibility are independent in Rust: ",[38,612,40],{}," on the struct only controls whether the ",[217,615,616],{},"struct type itself"," (and its ",[38,619,40],{}," fields\u002Fmethods) can be named from outside the module — each field still needs its own ",[38,622,40],{}," to be externally readable\u002Fwritable. This is a common gotcha (assumption A) because many other languages tie member visibility to the containing type's visibility. It's not scoped to same-crate access — ",[38,625,49],{}," would be needed for that specific behavior, and plain private means \"this module and descendants\" regardless of crate boundary (rules out C). There's no warning-only leniency here; it's a hard compile error (rules out D).",[14,628,629,640,670],{},[17,630,632,633,636,637,639],{"id":631},"q8-what-does-super-mean-in-a-use-path-or-item-path","Q8. What does ",[38,634,635],{},"super::"," mean in a ",[38,638,392],{}," path or item path?",[22,641,643,652,658,664],{"className":642},[25],[27,644,646,648,649],{"className":645},[30],[32,647],{"disabled":34,"type":35}," It refers to the crate root, equivalent to ",[38,650,651],{},"crate::",[27,653,655,657],{"className":654},[30],[32,656],{"disabled":34,"type":35}," It refers to the parent of the current module",[27,659,661,663],{"className":660},[30],[32,662],{"disabled":34,"type":35}," It refers to a trait's default (super) implementation",[27,665,667,669],{"className":666},[30],[32,668],{"disabled":34,"type":35}," It's not valid Rust syntax",[64,671,672,674,679],{},[67,673,69],{},[71,675,676,678],{},[74,677,76],{}," B — It refers to the parent of the current module",[71,680,681,36,683,686,687,690,691,694,695,697,698,700],{},[74,682,82],{},[38,684,685],{},"super"," is a relative-path keyword meaning \"one level up in the module tree\" — useful in a submodule (e.g. ",[38,688,689],{},"tests",") that needs to reach items defined in its parent, via ",[38,692,693],{},"use super::*;",". ",[38,696,651],{}," (confused with A) instead always means \"start from the absolute crate root,\" which is a different starting point unless the current module happens to be a direct child of the root. ",[38,699,685],{}," has nothing to do with trait default methods (rules out C), and it is valid, commonly used syntax (rules out D).",[14,702,703,725,763],{},[17,704,706,707,710,711,714,715,718,719,721,722,724],{"id":705},"q9-a-private-helper-function-is-defined-in-module-a-module-ab-is-a-child-module-declared-via-mod-b-inside-as-file-can-code-inside-ab-call-that-private-function","Q9. A private helper function is defined in module ",[38,708,709],{},"a",". Module ",[38,712,713],{},"a::b"," is a child module (declared via ",[38,716,717],{},"mod b;"," inside ",[38,720,709],{},"'s file). Can code inside ",[38,723,713],{}," call that private function?",[22,726,728,734,744,755],{"className":727},[25],[27,729,731,733],{"className":730},[30],[32,732],{"disabled":34,"type":35}," No — private items are never visible outside their exact defining module",[27,735,737,739,740,743],{"className":736},[30],[32,738],{"disabled":34,"type":35}," Yes — Rust's privacy rule makes a private item visible in its defining module ",[217,741,742],{},"and all of that module's descendants",", so child modules can see their ancestors' private items",[27,745,747,749,750,752,753],{"className":746},[30],[32,748],{"disabled":34,"type":35}," Only if ",[38,751,713],{}," adds ",[38,754,693],{},[27,756,758,760,761],{"className":757},[30],[32,759],{"disabled":34,"type":35}," Only if the function is also marked ",[38,762,49],{},[64,764,765,767,774],{},[67,766,69],{},[71,768,769,771,772,743],{},[74,770,76],{}," B — Yes — Rust's privacy rule makes a private item visible in its defining module ",[217,773,742],{},[71,775,776,778,779,781,782,784,785,788,789,792,793,796,797,799,800,802,803,805],{},[74,777,82],{}," This is one of Rust's most commonly-missed privacy rules: \"private\" is not \"only this module,\" it's \"this module plus everything nested inside it.\" A child module is considered part of its parent's privacy boundary, so ",[38,780,713],{}," can freely call a private (unmarked) item defined in ",[38,783,709],{}," by referring to it via a path like ",[38,786,787],{},"super::helper()",". A states the opposite of the actual rule. C conflates ",[217,790,791],{},"importing a name into scope"," with ",[217,794,795],{},"visibility"," — a ",[38,798,693],{}," would bring the name into unqualified scope for convenience, but ",[38,801,787],{}," would already compile without it, since visibility (not name resolution) is what was in question. D is unnecessary — no extra ",[38,804,49],{}," marker is needed for a descendant to see an ancestor's private item.",[14,807,808,819,861],{},[17,809,811,812,815,816,818],{"id":810},"q10-what-is-the-difference-between-pubsuper-and-pubcrate-on-an-item","Q10. What is the difference between ",[38,813,814],{},"pub(super)"," and ",[38,817,49],{}," on an item?",[22,820,822,828,839,850],{"className":821},[25],[27,823,825,827],{"className":824},[30],[32,826],{"disabled":34,"type":35}," They are identical",[27,829,831,36,833,835,836,838],{"className":830},[30],[32,832],{"disabled":34,"type":35},[38,834,814],{}," restricts visibility to just the parent module (and, transitively, that parent's descendants), while ",[38,837,49],{}," opens it to the entire crate",[27,840,842,36,844,846,847,849],{"className":841},[30],[32,843],{"disabled":34,"type":35},[38,845,814],{}," is for structs only, ",[38,848,49],{}," is for functions only",[27,851,853,36,855,857,858,860],{"className":852},[30],[32,854],{"disabled":34,"type":35},[38,856,814],{}," makes the item visible to external crates, ",[38,859,49],{}," does not",[64,862,863,865,874],{},[67,864,69],{},[71,866,867,869,870,835,872,838],{},[74,868,76],{}," B — ",[38,871,814],{},[38,873,49],{},[71,875,876,36,878,880,881,883,884,886],{},[74,877,82],{},[38,879,814],{}," is a narrower, path-scoped visibility modifier meaning \"visible to my parent module\" — useful for an item a submodule wants to expose upward without exposing it crate-wide. ",[38,882,49],{}," is broader, reaching every module in the crate regardless of position in the tree. They are not interchangeable (rules out A); both modifiers apply to any item kind — functions, structs, enums, modules — not restricted by kind (rules out C); and neither one reaches outside the crate at all — that requires plain ",[38,885,40],{}," (rules out D, which also has the external-visibility claim backwards).",[14,888,889,901,938],{},[17,890,892,893,815,895,897,898,900],{"id":891},"q11-what-happens-if-a-project-has-both-srcnetworkrs-and-srcnetworkmodrs-present-at-the-same-time-with-mod-network-declared-in-the-crate-root","Q11. What happens if a project has both ",[38,894,251],{},[38,896,259],{}," present at the same time, with ",[38,899,238],{}," declared in the crate root?",[22,902,904,910,923,932],{"className":903},[25],[27,905,907,909],{"className":906},[30],[32,908],{"disabled":34,"type":35}," The compiler merges both files' contents into one module",[27,911,913,915,916,919,920],{"className":912},[30],[32,914],{"disabled":34,"type":35}," The compiler picks ",[38,917,918],{},"network.rs"," and silently ignores ",[38,921,922],{},"network\u002Fmod.rs",[27,924,926,928,929,931],{"className":925},[30],[32,927],{"disabled":34,"type":35}," It's a compile error — the module ",[38,930,306],{}," would be ambiguously defined by two different files",[27,933,935,937],{"className":934},[30],[32,936],{"disabled":34,"type":35}," The compiler picks whichever file was modified more recently",[64,939,940,942,949],{},[67,941,69],{},[71,943,944,946,947,931],{},[74,945,76],{}," C — It's a compile error — the module ",[38,948,306],{},[71,950,951,953,954,957,958,961,962,964,965,967],{},[74,952,82],{}," The two module-file conventions (",[38,955,956],{},"name.rs"," vs ",[38,959,960],{},"name\u002Fmod.rs",") are alternatives, not layers that combine — the compiler requires exactly one to exist for a given ",[38,963,92],{}," declaration, and finding both is a \"file for module found at two places\" ambiguity error. This trips people up when migrating a codebase from the old ",[38,966,173],{}," convention to the new flat-file convention and forgetting to delete the old file. There's no merging (rules out A), no silent precedence (rules out B), and Rust's module resolution has nothing to do with filesystem timestamps (rules out D) — it's a static, deterministic error regardless of file mtimes.",[14,969,970,991,1033],{},[17,971,973,974,977,978,980,981,983,984,987,988,553],{"id":972},"q12-a-crate-has-pub-mod-net-pub-fn-connect-in-librs-but-nowhere-does-the-crate-write-use-for-connect-can-an-external-crate-that-depends-on-this-one-call-this_cratenetconnect","Q12. A crate has ",[38,975,976],{},"pub mod net { pub fn connect() {} }"," in ",[38,979,165],{},", but nowhere does the crate write ",[38,982,392],{}," for ",[38,985,986],{},"connect",". Can an external crate that depends on this one call ",[38,989,990],{},"this_crate::net::connect()",[22,992,994,1003,1015,1024],{"className":993},[25],[27,995,997,999,1000,1002],{"className":996},[30],[32,998],{"disabled":34,"type":35}," No — without an explicit ",[38,1001,392],{}," inside the defining crate, nothing is exported",[27,1004,1006,1008,1009,1011,1012,1014],{"className":1005},[30],[32,1007],{"disabled":34,"type":35}," Yes — ",[38,1010,40],{}," on both the module and the function is sufficient; ",[38,1013,392],{}," is unrelated to whether external crates can reach an item, it only affects local scoping within the defining crate itself",[27,1016,1018,1020,1021,1023],{"className":1017},[30],[32,1019],{"disabled":34,"type":35}," No — only items re-exported with ",[38,1022,425],{}," at the crate root are ever externally reachable",[27,1025,1027,1029,1030],{"className":1026},[30],[32,1028],{"disabled":34,"type":35}," Yes, but only if the external crate also declares ",[38,1031,1032],{},"mod net;",[64,1034,1035,1037,1046],{},[67,1036,69],{},[71,1038,1039,1041,1042,1011,1044,1014],{},[74,1040,76],{}," B — Yes — ",[38,1043,40],{},[38,1045,392],{},[71,1047,1048,1050,1051,1053,1054,1057,1058,1061,1062,1065,1066,1068,1069,1071,1072,1075,1076,409,1078,1080,1081,1083,1084,1087,1088,1090],{},[74,1049,82],{}," External reachability is governed entirely by the chain of ",[38,1052,40],{}," visibility from the crate root down to the item (",[38,1055,1056],{},"pub mod net"," + ",[38,1059,1060],{},"pub fn connect"," means the full path ",[38,1063,1064],{},"this_crate::net::connect"," is public), regardless of whether the defining crate itself ever writes a ",[38,1067,392],{}," for it internally. ",[38,1070,392],{}," only affects how ",[217,1073,1074],{},"that crate's own code"," refers to the item by a shorter name — it plays no role in what's exposed externally. A and C both overstate what ",[38,1077,392],{},[38,1079,425],{}," are required for: ",[38,1082,425],{}," is only needed if you want to expose the item under a ",[217,1085,1086],{},"different, shorter"," path than its natural one, not merely to expose it at all. D is not how Rust's module system works — a downstream crate accesses items through the dependency's public path, it doesn't need to mirror the internal module structure with its own ",[38,1089,92],{}," declaration.",[14,1092,1093,1116,1157],{},[17,1094,1096,1097,1100,1101,1104,1105,1107,1108,1111,1112,1115],{"id":1095},"q13-mod-shapes-privately-defines-pub-fn-circle_arear-f64-f64-and-a-private-non-pub-helper-fn-validater-f64-bool-elsewhere-code-does-use-shapes-what-becomes-available-at-the-call-site","Q13. ",[38,1098,1099],{},"mod shapes"," privately defines ",[38,1102,1103],{},"pub fn circle_area(r: f64) -> f64 {...}"," and a private (non-",[38,1106,40],{},") helper ",[38,1109,1110],{},"fn validate(r: f64) -> bool {...}",". Elsewhere, code does ",[38,1113,1114],{},"use shapes::*;",". What becomes available at the call site?",[22,1117,1119,1132,1143,1149],{"className":1118},[25],[27,1120,1122,1124,1125,815,1128,1131],{"className":1121},[30],[32,1123],{"disabled":34,"type":35}," Both ",[38,1126,1127],{},"circle_area",[38,1129,1130],{},"validate",", since glob imports bring in everything regardless of visibility",[27,1133,1135,248,1137,1139,1140],{"className":1134},[30],[32,1136],{"disabled":34,"type":35},[38,1138,1127],{}," — glob imports still respect normal privacy rules, so private items are never pulled in even by ",[38,1141,1142],{},"*",[27,1144,1146,1148],{"className":1145},[30],[32,1147],{"disabled":34,"type":35}," Neither — glob imports only work for enums, not modules",[27,1150,1152,248,1154,1156],{"className":1151},[30],[32,1153],{"disabled":34,"type":35},[38,1155,1130],{},", since glob imports prioritize private items",[64,1158,1159,1161,1170],{},[67,1160,69],{},[71,1162,1163,1165,1166,1139,1168],{},[74,1164,76],{}," B — Only ",[38,1167,1127],{},[38,1169,1142],{},[71,1171,1172,36,1174,1177,1178,1181,1182,1185,1186,1188,1189,1191,1192,1194,1195,1198,1199,1201,1202,1204],{},[74,1173,82],{},[38,1175,1176],{},"use path::*;"," is sugar for \"bring every ",[217,1179,1180],{},"visible-from-here"," item at ",[38,1183,1184],{},"path"," into scope\" — it is not a privacy bypass. Since ",[38,1187,1130],{}," has no ",[38,1190,40],{}," and the ",[38,1193,392],{}," site is outside ",[38,1196,1197],{},"shapes"," and its descendants, ",[38,1200,1130],{}," was never visible there to begin with, glob or not. Assuming ",[38,1203,1142],{}," reaches into private internals (A) is the tempting mistake; glob imports work for any module's contents, not just enum variants (rules out C, which describes a much narrower legitimate use of glob imports); and there's no such \"private items take priority\" behavior (rules out D).",[14,1206,1207,1237,1281],{},[17,1208,1210,1211,1213,1214,1217,1218,1220,1221,1224,1225,1227,1228,36,1231,1233,1234,1236],{"id":1209},"q14-mainrs-contains-in-this-order-mod-b-mod-a-where-as-code-calls-a-function-defined-in-b-and-bs-code-declared-textually-after-a-in-the-file-calls-a-function-defined-in-a-does-this-compile","Q14. ",[38,1212,181],{}," contains, in this order: ",[38,1215,1216],{},"mod b; mod a;"," where ",[38,1219,709],{},"'s code calls a function defined in ",[38,1222,1223],{},"b",", and ",[38,1226,1223],{},"'s code (declared textually ",[217,1229,1230],{},"after",[38,1232,709],{}," in the file) calls a function defined in ",[38,1235,709],{},". Does this compile?",[22,1238,1240,1258,1267,1273],{"className":1239},[25],[27,1241,1243,1245,1246,1248,1249,1251,1252,1254,1255,1257],{"className":1242},[30],[32,1244],{"disabled":34,"type":35}," No — ",[38,1247,1223],{}," is declared before ",[38,1250,709],{},", so ",[38,1253,709],{},"'s items don't exist yet when ",[38,1256,1223],{}," is compiled",[27,1259,1261,1263,1264,1266],{"className":1260},[30],[32,1262],{"disabled":34,"type":35}," Yes — Rust resolves the whole module graph before checking cross-references, so declaration order of ",[38,1265,92],{}," statements doesn't matter, unlike top-to-bottom execution order in scripting languages",[27,1268,1270,1272],{"className":1269},[30],[32,1271],{"disabled":34,"type":35}," No — mutual references between sibling modules are always a compile error",[27,1274,1276,1278,1279],{"className":1275},[30],[32,1277],{"disabled":34,"type":35}," Yes, but only if both modules are also marked ",[38,1280,40],{},[64,1282,1283,1285,1292],{},[67,1284,69],{},[71,1286,1287,1289,1290,1266],{},[74,1288,76],{}," B — Yes — Rust resolves the whole module graph before checking cross-references, so declaration order of ",[38,1291,92],{},[71,1293,1294,1296,1297,1299,1300,1302,1303,1306,1307,815,1309,1311,1312,1314],{},[74,1295,82],{}," Unlike C's single-pass, order-sensitive translation units, Rust builds a full module tree from all ",[38,1298,92],{}," declarations in the crate before resolving any paths, so two sibling modules can freely call into each other regardless of which ",[38,1301,92],{}," line appears first — there's no \"not declared yet\" state at the module-graph level. A projects familiar top-down\u002Fdeclaration-order thinking from other languages onto Rust, which is exactly the gotcha. Mutual references between modules are completely ordinary and common (rules out C) — Rust isn't a header-file\u002Fforward-declaration language. Visibility markers control whether ",[217,1304,1305],{},"other"," modules outside this pair can see the items, not whether ",[38,1308,709],{},[38,1310,1223],{}," can see each other as siblings in the same crate (rules out D, and here both functions only need to be visible to sibling modules, which private-by-default already permits per the ancestor\u002Fdescendant privacy rule, not ",[38,1313,40],{}," specifically).",[14,1316,1317,1321,1361],{},[17,1318,1320],{"id":1319},"q15-when-designing-a-librarys-public-api-which-is-the-more-idiomatic-structure","Q15. When designing a library's public API, which is the more idiomatic structure?",[22,1322,1324,1333,1346,1355],{"className":1323},[25],[27,1325,1327,1329,1330],{"className":1326},[30],[32,1328],{"disabled":34,"type":35}," Require consumers to import everything via deep paths like ",[38,1331,1332],{},"my_crate::internal::storage::backend::Client",[27,1334,1336,1338,1339,1341,1342,1345],{"className":1335},[30],[32,1337],{"disabled":34,"type":35}," Keep implementation details in whatever module nesting makes sense internally, then use ",[38,1340,425],{}," at the crate root (or a curated ",[38,1343,1344],{},"prelude"," module) to re-export the small set of types consumers actually need under short, stable paths",[27,1347,1349,1351,1352,1354],{"className":1348},[30],[32,1350],{"disabled":34,"type":35}," Make every module and item ",[38,1353,40],{}," so nothing is ever hidden",[27,1356,1358,1360],{"className":1357},[30],[32,1359],{"disabled":34,"type":35}," Avoid modules entirely and put all code in a single file to eliminate path issues",[64,1362,1363,1365,1374],{},[67,1364,69],{},[71,1366,1367,1369,1370,1341,1372,1345],{},[74,1368,76],{}," B — Keep implementation details in whatever module nesting makes sense internally, then use ",[38,1371,425],{},[38,1373,1344],{},[71,1375,1376,36,1378,1381,1382,1384,1385,1387],{},[74,1377,82],{},[74,1379,1380],{},"Idiom",": separating internal organization (which can change freely) from the public API surface (exposed via a small number of ",[38,1383,425],{}," re-exports) is standard practice in well-designed Rust crates — it lets internals be refactored without breaking downstream code, since only the re-exported paths are a semver commitment. Forcing consumers through deep internal paths (A) leaks implementation structure into your API contract, making future refactors breaking changes. Making everything ",[38,1386,40],{}," (C) is the opposite problem — it maximizes the semver-committed surface area, including things you'll want to change later. Avoiding modules altogether (D) doesn't scale and throws away the organizational and privacy benefits modules provide.",[14,1389,1390,1394,1427],{},[17,1391,1393],{"id":1392},"q16-for-a-helper-function-used-by-multiple-internal-modules-but-never-meant-to-be-called-by-downstream-crates-which-visibility-is-generally-the-better-default","Q16. For a helper function used by multiple internal modules but never meant to be called by downstream crates, which visibility is generally the better default?",[22,1395,1397,1405,1413,1419],{"className":1396},[25],[27,1398,1400,36,1402,1404],{"className":1399},[30],[32,1401],{"disabled":34,"type":35},[38,1403,40],{},", in case a downstream crate wants it someday",[27,1406,1408,36,1410,1412],{"className":1407},[30],[32,1409],{"disabled":34,"type":35},[38,1411,49],{}," — visible to every module inside this crate, but excluded from the crate's public API and semver contract",[27,1414,1416,1418],{"className":1415},[30],[32,1417],{"disabled":34,"type":35}," Leave it fully private and duplicate the function in every module that needs it",[27,1420,1422,36,1424,1426],{"className":1421},[30],[32,1423],{"disabled":34,"type":35},[38,1425,814],{},", regardless of whether the callers are actually siblings or unrelated modules",[64,1428,1429,1431,1437],{},[67,1430,69],{},[71,1432,1433,869,1435,1412],{},[74,1434,76],{},[38,1436,49],{},[71,1438,1439,36,1441,1443,1444,1446,1447,1449,1450,1452],{},[74,1440,82],{},[74,1442,1380],{},": ",[38,1445,49],{}," is the standard choice for \"shared internally, not part of the public contract\" — it gives every module in the crate access while keeping the item free to change or remove later without a semver-breaking release, since it was never externally reachable. Defaulting to ",[38,1448,40],{}," \"just in case\" (A) is a common anti-pattern that needlessly locks the signature into your public API forever. Duplicating the function per module (C) creates maintenance drift and defeats the purpose of having a module system. ",[38,1451,814],{}," (D) only works when every caller happens to be the direct parent module — reaching for it regardless of the actual caller locations is fragile and will break the moment a caller lives elsewhere in the tree.",[14,1454,1455,1462,1502],{},[17,1456,1458,1459,1461],{"id":1457},"q17-in-a-large-project-migrating-from-the-rust-2015-style-modrs-layout-to-the-modern-flat-file-layout-what-is-the-practical-motivation-the-community-usually-cites","Q17. In a large project migrating from the Rust 2015-style ",[38,1460,173],{}," layout to the modern flat-file layout, what is the practical motivation the community usually cites?",[22,1463,1465,1473,1485,1493],{"className":1464},[25],[27,1466,1468,36,1470,1472],{"className":1467},[30],[32,1469],{"disabled":34,"type":35},[38,1471,173],{}," files are compiled slower than flat files",[27,1474,1476,1478,1479,1481,1482,1484],{"className":1475},[30],[32,1477],{"disabled":34,"type":35}," Having many files all literally named ",[38,1480,173],{}," is hard to distinguish in editor tabs and file pickers, whereas ",[38,1483,918],{}," immediately identifies itself",[27,1486,1488,36,1490,1492],{"className":1487},[30],[32,1489],{"disabled":34,"type":35},[38,1491,173],{}," is deprecated and will be a hard compile error in a future edition",[27,1494,1496,1498,1499,1501],{"className":1495},[30],[32,1497],{"disabled":34,"type":35}," Only the flat-file style supports ",[38,1500,425],{}," re-exports",[64,1503,1504,1506,1515],{},[67,1505,69],{},[71,1507,1508,1510,1511,1481,1513,1484],{},[74,1509,76],{}," B — Having many files all literally named ",[38,1512,173],{},[38,1514,918],{},[71,1516,1517,36,1519,1521,1522,1524,1525,1527,1528,1530,1531,1533,1534,1537,1538,1540,1541,1543],{},[74,1518,82],{},[74,1520,1380],{},": both layouts compile to the identical module structure and have no performance difference, so the widely cited reason for preferring ",[38,1523,956],{}," over ",[38,1526,960],{}," is purely ergonomic — a dozen open ",[38,1529,173],{}," tabs are indistinguishable at a glance, while ",[38,1532,918],{},", ",[38,1535,1536],{},"parser.rs",", etc. are self-identifying. There's no compile-speed difference (rules out A), ",[38,1539,173],{}," remains fully supported and not deprecated in current editions (rules out C), and ",[38,1542,425],{}," re-exporting works identically regardless of which file-layout convention defines the module (rules out D).",[14,1545,1546,1557,1602],{},[17,1547,1549,1550,1553,1554,1556],{"id":1548},"q18-per-common-rust-formatting-convention-and-rustfmtclippy-defaults-how-should-use-statements-typically-be-grouped-at-the-top-of-a-file","Q18. Per common Rust formatting convention (and ",[38,1551,1552],{},"rustfmt","\u002Fclippy defaults), how should ",[38,1555,392],{}," statements typically be grouped at the top of a file?",[22,1558,1560,1566,1590,1596],{"className":1559},[25],[27,1561,1563,1565],{"className":1562},[30],[32,1564],{"disabled":34,"type":35}," In reverse-alphabetical order with no grouping",[27,1567,1569,1571,1572,409,1575,409,1578,1581,1582,409,1584,409,1587,1589],{"className":1568},[30],[32,1570],{"disabled":34,"type":35}," Grouped into standard library (",[38,1573,1574],{},"std",[38,1576,1577],{},"core",[38,1579,1580],{},"alloc","), external crate, and local crate (",[38,1583,651],{},[38,1585,1586],{},"self::",[38,1588,635],{},") blocks, each internally sorted",[27,1591,1593,1595],{"className":1592},[30],[32,1594],{"disabled":34,"type":35}," All on a single line separated by semicolons for compactness",[27,1597,1599,1601],{"className":1598},[30],[32,1600],{"disabled":34,"type":35}," Inline within each function right before first use, never at the top of the file",[64,1603,1604,1606,1623],{},[67,1605,69],{},[71,1607,1608,1610,1611,409,1613,409,1615,1581,1617,409,1619,409,1621,1589],{},[74,1609,76],{}," B — Grouped into standard library (",[38,1612,1574],{},[38,1614,1577],{},[38,1616,1580],{},[38,1618,651],{},[38,1620,1586],{},[38,1622,635],{},[71,1624,1625,36,1627,1629,1630,1632,1633,1635,1636,1639,1640,1643,1644,1646],{},[74,1626,82],{},[74,1628,1380],{},": separating ",[38,1631,392],{}," declarations into std \u002F external-crate \u002F local-crate groups (a convention ",[38,1634,1552],{}," can enforce with ",[38,1637,1638],{},"group_imports",", and that ",[38,1641,1642],{},"cargo fmt","\u002Fcommunity style guides converge on) makes it easy to scan a file's dependencies at a glance — what's from the standard library, what's a third-party crate, and what's local to this project. Reverse-alphabetical-only (A) ignores the semantic grouping that makes imports scannable. Cramming everything onto one line (C) is valid syntax but actively fights readability and diffing. Scattering ",[38,1645,392],{}," statements inline per-function (D) is unconventional in Rust — the idiom is top-of-file imports, unlike languages that favor fully local imports.",[14,1648,1649,1657,1692],{},[17,1650,1652,1653,1656],{"id":1651},"q19-why-is-a-blanket-pub-use-inner_module-at-a-crate-root-generally-discouraged-compared-to-explicitly-naming-re-exports","Q19. Why is a blanket ",[38,1654,1655],{},"pub use inner_module::*;"," at a crate root generally discouraged compared to explicitly naming re-exports?",[22,1658,1660,1666,1676,1682],{"className":1659},[25],[27,1661,1663,1665],{"className":1662},[30],[32,1664],{"disabled":34,"type":35}," It is a syntax error in current Rust editions",[27,1667,1669,1671,1672,1675],{"className":1668},[30],[32,1670],{"disabled":34,"type":35}," It obscures exactly what's part of the public API (making intentional vs. accidental exposure hard to audit) and risks silent re-export naming conflicts as ",[38,1673,1674],{},"inner_module"," evolves",[27,1677,1679,1681],{"className":1678},[30],[32,1680],{"disabled":34,"type":35}," Glob re-exports are always slower at runtime than named re-exports",[27,1683,1685,36,1687,792,1689,1691],{"className":1684},[30],[32,1686],{"disabled":34,"type":35},[38,1688,425],{},[38,1690,1142],{}," only works for enums",[64,1693,1694,1696,1703],{},[67,1695,69],{},[71,1697,1698,1700,1701,1675],{},[74,1699,76],{}," B — It obscures exactly what's part of the public API (making intentional vs. accidental exposure hard to audit) and risks silent re-export naming conflicts as ",[38,1702,1674],{},[71,1704,1705,36,1707,1709,1710,1712,1713,1716,1717,1719,1720,1722,1723,409,1725,1727],{},[74,1706,82],{},[74,1708,1380],{},": a glob ",[38,1711,425],{}," re-exports ",[217,1714,1715],{},"everything"," currently visible in ",[38,1718,1674],{},", including items added later that the author may not have intended to commit to the public API — every new item silently becomes part of the semver contract, and two glob-reexported modules that later both add an item of the same name produce a re-export collision far from where the actual conflict originates. Explicit, named ",[38,1721,425],{}," statements make the public surface auditable at a glance and immune to that drift. It's valid, working syntax, not an error (rules out A); there is no runtime cost difference — ",[38,1724,392],{},[38,1726,425],{}," are purely a compile-time path\u002Fname resolution mechanism with zero runtime representation (rules out C); and glob re-exports work for any module's public contents, not just enums (rules out D).",[14,1729,1730,1766,1830],{},[17,1731,1733,1734,1533,1737,1740,1741,1744,1745,815,1748,1751,1752,1755,1756,1758,1759,1761,1762,1765],{"id":1732},"q20-a-crate-is-organized-as-srclibrs-srcnetmodrs-or-srcnetrs-declaring-pubcrate-mod-client-and-srcnetclientrs-defining-pub-struct-client-with-mostly-pubcrate-helper-functions-alongside-it-librs-also-contains-pub-use-netclientclient-what-is-the-effect-of-this-structure-for-a-downstream-crate","Q20. A crate is organized as ",[38,1735,1736],{},"src\u002Flib.rs",[38,1738,1739],{},"src\u002Fnet\u002Fmod.rs"," (or ",[38,1742,1743],{},"src\u002Fnet.rs",") declaring ",[38,1746,1747],{},"pub(crate) mod client;",[38,1749,1750],{},"src\u002Fnet\u002Fclient.rs"," defining ",[38,1753,1754],{},"pub struct Client { ... }"," with mostly ",[38,1757,49],{}," helper functions alongside it. ",[38,1760,165],{}," also contains ",[38,1763,1764],{},"pub use net::client::Client;",". What is the effect of this structure for a downstream crate?",[22,1767,1769,1785,1797,1818],{"className":1768},[25],[27,1770,1772,1774,1775,1778,1779,1782,1783],{"className":1771},[30],[32,1773],{"disabled":34,"type":35}," It cannot see ",[38,1776,1777],{},"Client"," at all, since ",[38,1780,1781],{},"net"," itself is only ",[38,1784,49],{},[27,1786,1788,1790,1791,1793,1794],{"className":1787},[30],[32,1789],{"disabled":34,"type":35}," It can reach ",[38,1792,1777],{}," only via the full path ",[38,1795,1796],{},"this_crate::net::client::Client",[27,1798,1800,1790,1802,1804,1805,1808,1809,409,1811,1814,1815,1817],{"className":1799},[30],[32,1801],{"disabled":34,"type":35},[38,1803,1777],{}," via the short, stable path ",[38,1806,1807],{},"this_crate::Client",", while the ",[38,1810,1781],{},[38,1812,1813],{},"client"," module layout and any ",[38,1816,49],{}," helpers stay fully internal and free to refactor",[27,1819,1821,1823,1824,1826,1827,1829],{"className":1820},[30],[32,1822],{"disabled":34,"type":35}," It gets a compile error because ",[38,1825,425],{}," cannot re-export an item from a ",[38,1828,49],{}," module",[64,1831,1832,1834,1849],{},[67,1833,69],{},[71,1835,1836,1838,1839,1804,1841,1808,1843,409,1845,1814,1847,1817],{},[74,1837,76],{}," C — It can reach ",[38,1840,1777],{},[38,1842,1807],{},[38,1844,1781],{},[38,1846,1813],{},[38,1848,49],{},[71,1850,1851,1853,1854,1856,1857,1859,1860,1862,1863,1865,1866,1868,1869,1871,1872,1874,1875,1877,1878,1880,1881,1883,1884,1887,1888,1890,1891,1893,1894,1896],{},[74,1852,82],{}," This is the idiomatic re-export pattern in practice: ",[38,1855,1781],{}," being merely ",[38,1858,49],{}," would normally block external access to anything nested inside it, but the ",[38,1861,1764],{}," at the crate root creates an independent, fully ",[38,1864,40],{}," path directly to ",[38,1867,1777],{}," that does not depend on ",[38,1870,1781],{},"'s own visibility — re-export visibility is evaluated at the ",[38,1873,425],{}," site, not inherited from the source module's visibility. A is the tempting mistake of assuming a ",[38,1876,425],{}," inherits its source module's restricted visibility rather than establishing its own. B undersells the re-export — the whole point of ",[38,1879,425],{}," is to avoid forcing consumers through the internal path. D is wrong: re-exporting an item out of a less-visible module into a more-visible path is exactly what ",[38,1882,425],{}," is for and is a completely standard, compiling pattern, as long as the ",[217,1885,1886],{},"item itself"," (",[38,1889,1777],{},") is at least as visible as the path you're re-exporting it to (",[38,1892,1777],{}," is ",[38,1895,40],{},", so this works).",{"title":1898,"searchDepth":1899,"depth":1899,"links":1900},"",2,[1901,1903,1905,1906,1908,1910,1912,1914,1916,1918,1920,1922,1924,1926,1928,1929,1930,1932,1934,1936],{"id":19,"depth":1902,"text":20},3,{"id":98,"depth":1902,"text":1904},"Q2. What does pub(crate) mean when applied to a function?",{"id":153,"depth":1902,"text":154},{"id":231,"depth":1902,"text":1907},"Q4. Given src\u002Fmain.rs contains mod network;, which file layouts are valid ways to provide that module's contents (Rust 2018+)?",{"id":330,"depth":1902,"text":1909},"Q5. What does use crate::utils::parse; do?",{"id":431,"depth":1902,"text":1911},"Q6. What is the purpose of pub use inner::Thing; written in a parent module?",{"id":544,"depth":1902,"text":1913},"Q7. Given pub struct Config { pub name: String, version: u32 }, what is true about a caller outside the module accessing config.version?",{"id":631,"depth":1902,"text":1915},"Q8. What does super:: mean in a use path or item path?",{"id":705,"depth":1902,"text":1917},"Q9. A private helper function is defined in module a. Module a::b is a child module (declared via mod b; inside a's file). Can code inside a::b call that private function?",{"id":810,"depth":1902,"text":1919},"Q10. What is the difference between pub(super) and pub(crate) on an item?",{"id":891,"depth":1902,"text":1921},"Q11. What happens if a project has both src\u002Fnetwork.rs and src\u002Fnetwork\u002Fmod.rs present at the same time, with mod network; declared in the crate root?",{"id":972,"depth":1902,"text":1923},"Q12. A crate has pub mod net { pub fn connect() {} } in lib.rs, but nowhere does the crate write use for connect. Can an external crate that depends on this one call this_crate::net::connect()?",{"id":1095,"depth":1902,"text":1925},"Q13. mod shapes privately defines pub fn circle_area(r: f64) -> f64 {...} and a private (non-pub) helper fn validate(r: f64) -> bool {...}. Elsewhere, code does use shapes::*;. What becomes available at the call site?",{"id":1209,"depth":1902,"text":1927},"Q14. main.rs contains, in this order: mod b; mod a; where a's code calls a function defined in b, and b's code (declared textually after a in the file) calls a function defined in a. Does this compile?",{"id":1319,"depth":1902,"text":1320},{"id":1392,"depth":1902,"text":1393},{"id":1457,"depth":1902,"text":1931},"Q17. In a large project migrating from the Rust 2015-style mod.rs layout to the modern flat-file layout, what is the practical motivation the community usually cites?",{"id":1548,"depth":1902,"text":1933},"Q18. Per common Rust formatting convention (and rustfmt\u002Fclippy defaults), how should use statements typically be grouped at the top of a file?",{"id":1651,"depth":1902,"text":1935},"Q19. Why is a blanket pub use inner_module::*; at a crate root generally discouraged compared to explicitly naming re-exports?",{"id":1732,"depth":1902,"text":1937},"Q20. A crate is organized as src\u002Flib.rs, src\u002Fnet\u002Fmod.rs (or src\u002Fnet.rs) declaring pub(crate) mod client; and src\u002Fnet\u002Fclient.rs defining pub struct Client { ... } with mostly pub(crate) helper functions alongside it. lib.rs also contains pub use net::client::Client;. What is the effect of this structure for a downstream crate?","md",{},"\u002Frust\u002F20-modules-and-crates",{"title":5,"description":1898},"rust\u002F20-modules-and-crates","Bq-AXdlvi7Hid41CD5OrLkQWuUC01aoMx3YASVgjh1k",1787335398414]