[{"data":1,"prerenderedAt":2478},["ShallowReactive",2],{"page-\u002Frust\u002F11-structs":3},{"id":4,"title":5,"body":6,"description":35,"extension":2472,"meta":2473,"navigation":142,"path":2474,"seo":2475,"stem":2476,"__hash__":2477},"content\u002Frust\u002F11-structs.md","11 — Structs",{"type":7,"value":8,"toc":2450},"minimark",[9,13,249,354,444,657,734,957,1022,1287,1373,1573,1663,2446],[10,11,5],"h1",{"id":12},"_11-structs",[14,15,17,27,129,192],"question-wrapper",{"language":16},"rust",[18,19,21,22,26],"h3",{"id":20},"q1-given-struct-user-name-string-age-u8-active-bool-what-does-struct-update-syntax-do-here","Q1. Given ",[23,24,25],"code",{},"struct User { name: String, age: u8, active: bool }",", what does struct update syntax do here?",[28,29,30],"code-wrapper",{"language":16},[31,32,36],"pre",{"className":33,"code":34,"language":16,"meta":35,"style":35},"language-rust shiki shiki-themes github-light github-dark","let base = User { name: String::from(\"Alice\"), age: 30, active: true };\nlet updated = User { age: 31, ..base };\n","",[23,37,38,100],{"__ignoreMap":35},[39,40,43,47,51,54,58,61,64,67,70,73,76,80,83,85,89,92,94,97],"span",{"class":41,"line":42},"line",1,[39,44,46],{"class":45},"svdQ7","let",[39,48,50],{"class":49},"ssxIu"," base ",[39,52,53],{"class":45},"=",[39,55,57],{"class":56},"sIsaT"," User",[39,59,60],{"class":49}," { name",[39,62,63],{"class":45},":",[39,65,66],{"class":56}," String",[39,68,69],{"class":45},"::",[39,71,72],{"class":56},"from",[39,74,75],{"class":49},"(",[39,77,79],{"class":78},"sJ6F3","\"Alice\"",[39,81,82],{"class":49},"), age",[39,84,63],{"class":45},[39,86,88],{"class":87},"snvgF"," 30",[39,90,91],{"class":49},", active",[39,93,63],{"class":45},[39,95,96],{"class":87}," true",[39,98,99],{"class":49}," };\n",[39,101,103,105,108,110,112,115,117,120,123,126],{"class":41,"line":102},2,[39,104,46],{"class":45},[39,106,107],{"class":49}," updated ",[39,109,53],{"class":45},[39,111,57],{"class":56},[39,113,114],{"class":49}," { age",[39,116,63],{"class":45},[39,118,119],{"class":87}," 31",[39,121,122],{"class":49},", ",[39,124,125],{"class":45},"..",[39,127,128],{"class":49},"base };\n",[130,131,134,152,171,183],"ul",{"className":132},[133],"contains-task-list",[135,136,139,144,145,148,149],"li",{"className":137},[138],"task-list-item",[140,141],"input",{"disabled":142,"type":143},true,"checkbox"," It mutates ",[23,146,147],{},"base"," in place, changing only ",[23,150,151],{},"age",[135,153,155,157,158,161,162,164,165,167,168],{"className":154},[138],[140,156],{"disabled":142,"type":143}," It creates a new ",[23,159,160],{},"User",", copying\u002Fmoving every field not explicitly listed from ",[23,163,147],{},", and ",[23,166,151],{}," overrides ",[23,169,170],{},"base.age",[135,172,174,176,177,179,180],{"className":173},[138],[140,175],{"disabled":142,"type":143}," It merges ",[23,178,147],{}," and the new fields into a ",[23,181,182],{},"HashMap",[135,184,186,188,189,191],{"className":185},[138],[140,187],{"disabled":142,"type":143}," It fails to compile because ",[23,190,125],{}," requires all fields to be listed",[193,194,195,199,215],"details",{},[196,197,198],"summary",{},"Show Answer",[200,201,202,206,207,161,209,164,211,167,213],"p",{},[203,204,205],"strong",{},"Answer:"," B — It creates a new ",[23,208,160],{},[23,210,147],{},[23,212,151],{},[23,214,170],{},[200,216,217,220,221,224,225,227,228,231,232,234,235,237,238,240,241,243,244,248],{},[203,218,219],{},"Explanation:"," ",[23,222,223],{},"..base"," fills in every remaining field from ",[23,226,147],{},", field-by-field, as if you'd written ",[23,229,230],{},"name: base.name, active: base.active"," yourself. It does not mutate ",[23,233,147],{}," — it constructs an entirely new value. A is wrong because ",[23,236,147],{}," is left untouched (aside from any fields moved out of it, see later questions). C is a fabricated behavior; struct update syntax has nothing to do with ",[23,239,182],{},". D is wrong — ",[23,242,223],{}," is exactly the mechanism that lets you ",[245,246,247],"em",{},"avoid"," listing every field.",[14,250,251,255,282,326],{"language":16},[18,252,254],{"id":253},"q2-what-kind-of-struct-is-this-and-how-do-you-construct-one","Q2. What kind of struct is this, and how do you construct one?",[28,256,257],{"language":16},[31,258,260],{"className":33,"code":259,"language":16,"meta":35,"style":35},"struct Point(f64, f64);\n",[23,261,262],{"__ignoreMap":35},[39,263,264,267,270,272,275,277,279],{"class":41,"line":42},[39,265,266],{"class":45},"struct",[39,268,269],{"class":56}," Point",[39,271,75],{"class":49},[39,273,274],{"class":56},"f64",[39,276,122],{"class":49},[39,278,274],{"class":56},[39,280,281],{"class":49},");\n",[130,283,285,294,311,320],{"className":284},[133],[135,286,288,290,291],{"className":287},[138],[140,289],{"disabled":142,"type":143}," A unit struct; construct with ",[23,292,293],{},"Point;",[135,295,297,299,300,303,304,307,308],{"className":296},[138],[140,298],{"disabled":142,"type":143}," A tuple struct; construct with ",[23,301,302],{},"Point(1.0, 2.0)",", and access fields with ",[23,305,306],{},".0"," and ",[23,309,310],{},".1",[135,312,314,316,317],{"className":313},[138],[140,315],{"disabled":142,"type":143}," An enum variant; construct with ",[23,318,319],{},"Point::new(1.0, 2.0)",[135,321,323,325],{"className":322},[138],[140,324],{"disabled":142,"type":143}," Invalid syntax — structs require named fields",[193,327,328,330,341],{},[196,329,198],{},[200,331,332,334,335,303,337,307,339],{},[203,333,205],{}," B — A tuple struct; construct with ",[23,336,302],{},[23,338,306],{},[23,340,310],{},[200,342,343,345,346,349,350,353],{},[203,344,219],{}," Tuple structs have a name but unnamed, positionally-indexed fields, giving you a distinct type (unlike a plain ",[23,347,348],{},"(f64, f64)"," tuple) while keeping tuple-like ergonomics. A confuses this with a unit struct (",[23,351,352],{},"struct Marker;",", zero fields). C is false — this is not enum syntax at all. D is wrong — tuple structs with unnamed positional fields are valid, standard Rust.",[14,355,356,360,377,411],{"language":16},[18,357,359],{"id":358},"q3-what-is-a-unit-struct-and-what-is-it-typically-used-for","Q3. What is a \"unit struct,\" and what is it typically used for?",[28,361,362],{"language":16},[31,363,365],{"className":33,"code":364,"language":16,"meta":35,"style":35},"struct Meters;\n",[23,366,367],{"__ignoreMap":35},[39,368,369,371,374],{"class":41,"line":42},[39,370,266],{"class":45},[39,372,373],{"class":56}," Meters",[39,375,376],{"class":49},";\n",[130,378,380,386,392,402],{"className":379},[133],[135,381,383,385],{"className":382},[138],[140,384],{"disabled":142,"type":143}," A struct with exactly one field",[135,387,389,391],{"className":388},[138],[140,390],{"disabled":142,"type":143}," A zero-sized struct with no fields at all, commonly used as a marker type or to implement a trait with no data",[135,393,395,397,398,401],{"className":394},[138],[140,396],{"disabled":142,"type":143}," A struct that can only hold ",[23,399,400],{},"u8"," values",[135,403,405,407,408],{"className":404},[138],[140,406],{"disabled":142,"type":143}," Shorthand for ",[23,409,410],{},"struct Meters { value: () }",[193,412,413,415,420],{},[196,414,198],{},[200,416,417,419],{},[203,418,205],{}," B — A zero-sized struct with no fields at all, commonly used as a marker type or to implement a trait with no data",[200,421,422,220,424,427,428,431,432,435,436,439,440,443],{},[203,423,219],{},[23,425,426],{},"struct Meters;"," declares a type with zero size and zero fields — it exists purely at the type level, useful for marker types, phantom-type tags, or as a target for trait implementations where behavior matters but data doesn't. A confuses it with a newtype\u002Ftuple struct holding one value. C is fabricated. D is close conceptually but wrong mechanically — a unit struct has no field at all, not an explicit ",[23,429,430],{},"()"," field; ",[23,433,434],{},"size_of::\u003CMeters>()"," is ",[23,437,438],{},"0",", same as ",[23,441,442],{},"size_of::\u003C()>()",", but they are different types.",[14,445,446,454,563,620],{"language":16},[18,447,449,450,453],{"id":448},"q4-whats-the-essential-difference-between-these-two-impl-block-items","Q4. What's the essential difference between these two ",[23,451,452],{},"impl"," block items?",[28,455,456],{"language":16},[31,457,459],{"className":33,"code":458,"language":16,"meta":35,"style":35},"impl Rectangle {\n    fn area(&self) -> u32 { self.width * self.height }\n    fn square(size: u32) -> Rectangle { Rectangle { width: size, height: size } }\n}\n",[23,460,461,471,518,557],{"__ignoreMap":35},[39,462,463,465,468],{"class":41,"line":42},[39,464,452],{"class":45},[39,466,467],{"class":56}," Rectangle",[39,469,470],{"class":49}," {\n",[39,472,473,476,479,481,484,487,490,493,496,499,501,504,507,510,513,515],{"class":41,"line":102},[39,474,475],{"class":45},"    fn",[39,477,478],{"class":56}," area",[39,480,75],{"class":49},[39,482,483],{"class":45},"&",[39,485,486],{"class":87},"self",[39,488,489],{"class":49},") ",[39,491,492],{"class":45},"->",[39,494,495],{"class":56}," u32",[39,497,498],{"class":49}," { ",[39,500,486],{"class":87},[39,502,503],{"class":45},".",[39,505,506],{"class":49},"width ",[39,508,509],{"class":45},"*",[39,511,512],{"class":87}," self",[39,514,503],{"class":45},[39,516,517],{"class":49},"height }\n",[39,519,521,523,526,529,531,533,535,537,539,541,544,547,549,552,554],{"class":41,"line":520},3,[39,522,475],{"class":45},[39,524,525],{"class":56}," square",[39,527,528],{"class":49},"(size",[39,530,63],{"class":45},[39,532,495],{"class":56},[39,534,489],{"class":49},[39,536,492],{"class":45},[39,538,467],{"class":56},[39,540,498],{"class":49},[39,542,543],{"class":56},"Rectangle",[39,545,546],{"class":49}," { width",[39,548,63],{"class":45},[39,550,551],{"class":49}," size, height",[39,553,63],{"class":45},[39,555,556],{"class":49}," size } }\n",[39,558,560],{"class":41,"line":559},4,[39,561,562],{"class":49},"}\n",[130,564,566,579,603,609],{"className":565},[133],[135,567,569,220,571,574,575,578],{"className":568},[138],[140,570],{"disabled":142,"type":143},[23,572,573],{},"area"," is an associated function; ",[23,576,577],{},"square"," is a method",[135,580,582,220,584,586,587,589,590,593,594,596,597,589,599,602],{"className":581},[138],[140,583],{"disabled":142,"type":143},[23,585,573],{}," is a method (takes ",[23,588,486],{},", called as ",[23,591,592],{},"rect.area()","); ",[23,595,577],{}," is an associated function (no ",[23,598,486],{},[23,600,601],{},"Rectangle::square(5)",")",[135,604,606,608],{"className":605},[138],[140,607],{"disabled":142,"type":143}," Both are methods, just with different return types",[135,610,612,220,614,616,617,619],{"className":611},[138],[140,613],{"disabled":142,"type":143},[23,615,577],{}," cannot be called without first creating a ",[23,618,543],{}," instance",[193,621,622,624,641],{},[196,623,198],{},[200,625,626,628,629,586,631,589,633,593,635,596,637,589,639,602],{},[203,627,205],{}," B — ",[23,630,573],{},[23,632,486],{},[23,634,592],{},[23,636,577],{},[23,638,486],{},[23,640,601],{},[200,642,643,645,646,648,649,652,653,656],{},[203,644,219],{}," The presence or absence of a ",[23,647,486],{}," parameter is exactly what distinguishes a method from an associated function in Rust terminology. ",[23,650,651],{},"Rectangle::new","-style constructors are the classic associated-function use case, since you don't yet have an instance to call a method on. A has the terms backwards. C ignores the defining distinction. D is backwards — associated functions are exactly the tool for building the ",[245,654,655],{},"first"," instance, callable without any existing value.",[14,658,659,671,706],{},[18,660,662,663,666,667,670],{"id":661},"q5-which-method-receiver-should-fn-describeself-string-use-if-it-only-needs-to-read-fields-and-return-a-new-owned-string","Q5. Which method receiver should ",[23,664,665],{},"fn describe(&self) -> String"," use if it only needs to read fields and return a new owned ",[23,668,669],{},"String","?",[130,672,674,682,690,698],{"className":673},[133],[135,675,677,220,679,681],{"className":676},[138],[140,678],{"disabled":142,"type":143},[23,680,486],{}," (take ownership)",[135,683,685,220,687],{"className":684},[138],[140,686],{"disabled":142,"type":143},[23,688,689],{},"&mut self",[135,691,693,220,695],{"className":692},[138],[140,694],{"disabled":142,"type":143},[23,696,697],{},"&self",[135,699,701,220,703],{"className":700},[138],[140,702],{"disabled":142,"type":143},[23,704,705],{},"&&self",[193,707,708,710,717],{},[196,709,198],{},[200,711,712,714,715],{},[203,713,205],{}," C — ",[23,716,697],{},[200,718,719,721,722,724,725,727,728,730,731,733],{},[203,720,219],{}," Reading fields without needing to mutate or consume the struct calls for an immutable borrow, ",[23,723,697],{}," — this is by far the most common receiver, and it lets the caller keep using the instance afterward. ",[23,726,486],{}," (A) would consume the instance, making it unusable after the call, which is unnecessary overhead and an ergonomics regression if the caller wanted to keep the value. ",[23,729,689],{}," (B) would needlessly require the caller to have (or make) a mutable binding when no mutation happens. ",[23,732,705],{}," (D) is not valid receiver syntax.",[14,735,736,746,855,902],{"language":16},[18,737,739,740,742,743,745],{"id":738},"q6-what-does-calling-a-method-that-takes-self-by-value-not-self-do-to-the-original-variable","Q6. What does calling a method that takes ",[23,741,486],{}," (by value, not ",[23,744,697],{},") do to the original variable?",[28,747,748],{"language":16},[31,749,751],{"className":33,"code":750,"language":16,"meta":35,"style":35},"struct Wrapper(String);\nimpl Wrapper {\n    fn into_inner(self) -> String { self.0 }\n}\nlet w = Wrapper(String::from(\"data\"));\nlet s = w.into_inner();\n",[23,752,753,766,774,802,806,834],{"__ignoreMap":35},[39,754,755,757,760,762,764],{"class":41,"line":42},[39,756,266],{"class":45},[39,758,759],{"class":56}," Wrapper",[39,761,75],{"class":49},[39,763,669],{"class":56},[39,765,281],{"class":49},[39,767,768,770,772],{"class":41,"line":102},[39,769,452],{"class":45},[39,771,759],{"class":56},[39,773,470],{"class":49},[39,775,776,778,781,783,785,787,789,791,793,795,797,799],{"class":41,"line":520},[39,777,475],{"class":45},[39,779,780],{"class":56}," into_inner",[39,782,75],{"class":49},[39,784,486],{"class":87},[39,786,489],{"class":49},[39,788,492],{"class":45},[39,790,66],{"class":56},[39,792,498],{"class":49},[39,794,486],{"class":87},[39,796,503],{"class":45},[39,798,438],{"class":87},[39,800,801],{"class":49}," }\n",[39,803,804],{"class":41,"line":559},[39,805,562],{"class":49},[39,807,809,811,814,816,818,820,822,824,826,828,831],{"class":41,"line":808},5,[39,810,46],{"class":45},[39,812,813],{"class":49}," w ",[39,815,53],{"class":45},[39,817,759],{"class":56},[39,819,75],{"class":49},[39,821,669],{"class":56},[39,823,69],{"class":45},[39,825,72],{"class":56},[39,827,75],{"class":49},[39,829,830],{"class":78},"\"data\"",[39,832,833],{"class":49},"));\n",[39,835,837,839,842,844,847,849,852],{"class":41,"line":836},6,[39,838,46],{"class":45},[39,840,841],{"class":49}," s ",[39,843,53],{"class":45},[39,845,846],{"class":49}," w",[39,848,503],{"class":45},[39,850,851],{"class":56},"into_inner",[39,853,854],{"class":49},"();\n",[130,856,858,867,881,889],{"className":857},[133],[135,859,861,220,863,866],{"className":860},[138],[140,862],{"disabled":142,"type":143},[23,864,865],{},"w"," is still usable after the call, since Rust copies structs implicitly",[135,868,870,220,872,874,875,877,878,880],{"className":869},[138],[140,871],{"disabled":142,"type":143},[23,873,865],{}," is moved into ",[23,876,851],{},", so using ",[23,879,865],{}," again after this line is a compile error",[135,882,884,220,886,888],{"className":883},[138],[140,885],{"disabled":142,"type":143},[23,887,865],{}," is automatically cloned before the call",[135,890,892,894,895,898,899],{"className":891},[138],[140,893],{"disabled":142,"type":143}," This only compiles if ",[23,896,897],{},"Wrapper"," derives ",[23,900,901],{},"Copy",[193,903,904,906,916],{},[196,905,198],{},[200,907,908,628,910,874,912,877,914,880],{},[203,909,205],{},[23,911,865],{},[23,913,851],{},[23,915,865],{},[200,917,918,920,921,923,924,926,927,929,930,932,933,935,936,938,939,941,942,220,944,947,948,122,950,952,953,220,955,503],{},[203,919,219],{}," A ",[23,922,486],{},"-by-value receiver takes ownership, exactly like passing ",[23,925,865],{}," to any function that takes ",[23,928,897],{}," by value — ",[23,931,897],{}," contains a ",[23,934,669],{},", which is not ",[23,937,901],{},", so this is a move, not a copy. Any later use of ",[23,940,865],{}," triggers \"use of moved value.\" A is the common mistaken assumption from languages with reference semantics by default. C is false — Rust never inserts implicit clones. D is backwards — if ",[23,943,897],{},[245,945,946],{},"did"," derive ",[23,949,901],{},[23,951,865],{}," would still be usable afterward because the value gets copied instead of moved, but that's not the case here since it contains a non-",[23,954,901],{},[23,956,669],{},[14,958,959,967,994],{},[18,960,962,963,966],{"id":961},"q7-what-visibility-do-struct-fields-have-by-default-inside-their-own-module-if-declared-without-a-pub-keyword","Q7. What visibility do struct fields have by default, inside their own module, if declared without a ",[23,964,965],{},"pub"," keyword?",[130,968,970,976,982,988],{"className":969},[133],[135,971,973,975],{"className":972},[138],[140,974],{"disabled":142,"type":143}," Public everywhere by default",[135,977,979,981],{"className":978},[138],[140,980],{"disabled":142,"type":143}," Private — accessible only within the module the struct is defined in (and its descendants)",[135,983,985,987],{"className":984},[138],[140,986],{"disabled":142,"type":143}," Public within the same crate only, regardless of module",[135,989,991,993],{"className":990},[138],[140,992],{"disabled":142,"type":143}," Fields have no visibility concept; only whole structs can be public or private",[193,995,996,998,1003],{},[196,997,198],{},[200,999,1000,1002],{},[203,1001,205],{}," B — Private — accessible only within the module the struct is defined in (and its descendants)",[200,1004,1005,1007,1008,1010,1011,1014,1015,1018,1019,1021],{},[203,1006,219],{}," Struct fields are private by default, even if the struct itself is ",[23,1009,965],{}," — this is a frequent surprise for newcomers who mark ",[23,1012,1013],{},"pub struct Foo"," and then can't access ",[23,1016,1017],{},"foo.bar"," from another module until they also add ",[23,1020,965],{}," to the field itself. A is wrong and is the exact misconception this trips people on. C invents a crate-wide default that doesn't exist. D is false — Rust does apply per-field visibility, independent of the struct's own visibility.",[14,1023,1024,1035,1141,1204],{"language":16},[18,1025,1027,1028,1030,1031,1034],{"id":1026},"q8-what-happens-when-you-use-struct-update-syntax-where-the-base-struct-contains-a-non-copy-field-that-you-dont-override","Q8. What happens when you use struct update syntax where the base struct contains a non-",[23,1029,901],{}," field that you ",[245,1032,1033],{},"don't"," override?",[28,1036,1037],{"language":16},[31,1038,1040],{"className":33,"code":1039,"language":16,"meta":35,"style":35},"struct Config { name: String, retries: u32 }\nlet base = Config { name: String::from(\"svc\"), retries: 3 };\nlet updated = Config { retries: 5, ..base };\nprintln!(\"{}\", base.name);\n",[23,1041,1042,1064,1099,1123],{"__ignoreMap":35},[39,1043,1044,1046,1049,1051,1053,1055,1058,1060,1062],{"class":41,"line":42},[39,1045,266],{"class":45},[39,1047,1048],{"class":56}," Config",[39,1050,60],{"class":49},[39,1052,63],{"class":45},[39,1054,66],{"class":56},[39,1056,1057],{"class":49},", retries",[39,1059,63],{"class":45},[39,1061,495],{"class":56},[39,1063,801],{"class":49},[39,1065,1066,1068,1070,1072,1074,1076,1078,1080,1082,1084,1086,1089,1092,1094,1097],{"class":41,"line":102},[39,1067,46],{"class":45},[39,1069,50],{"class":49},[39,1071,53],{"class":45},[39,1073,1048],{"class":56},[39,1075,60],{"class":49},[39,1077,63],{"class":45},[39,1079,66],{"class":56},[39,1081,69],{"class":45},[39,1083,72],{"class":56},[39,1085,75],{"class":49},[39,1087,1088],{"class":78},"\"svc\"",[39,1090,1091],{"class":49},"), retries",[39,1093,63],{"class":45},[39,1095,1096],{"class":87}," 3",[39,1098,99],{"class":49},[39,1100,1101,1103,1105,1107,1109,1112,1114,1117,1119,1121],{"class":41,"line":520},[39,1102,46],{"class":45},[39,1104,107],{"class":49},[39,1106,53],{"class":45},[39,1108,1048],{"class":56},[39,1110,1111],{"class":49}," { retries",[39,1113,63],{"class":45},[39,1115,1116],{"class":87}," 5",[39,1118,122],{"class":49},[39,1120,125],{"class":45},[39,1122,128],{"class":49},[39,1124,1125,1128,1130,1133,1136,1138],{"class":41,"line":559},[39,1126,1127],{"class":56},"println!",[39,1129,75],{"class":49},[39,1131,1132],{"class":78},"\"{}\"",[39,1134,1135],{"class":49},", base",[39,1137,503],{"class":45},[39,1139,1140],{"class":49},"name);\n",[130,1142,1144,1157,1180,1188],{"className":1143},[133],[135,1145,1147,1149,1150,1153,1154,1156],{"className":1146},[138],[140,1148],{"disabled":142,"type":143}," Compiles fine — ",[23,1151,1152],{},"base.name"," is still accessible because ",[23,1155,223],{}," only borrows",[135,1158,1160,1162,1163,1166,1167,1169,1170,1173,1174,1176,1177,1179],{"className":1159},[138],[140,1161],{"disabled":142,"type":143}," Fails to compile — ",[23,1164,1165],{},"name"," is moved out of ",[23,1168,147],{}," into ",[23,1171,1172],{},"updated",", so ",[23,1175,147],{}," (or at least ",[23,1178,1152],{},") can no longer be used as a whole",[135,1181,1183,220,1185,1187],{"className":1182},[138],[140,1184],{"disabled":142,"type":143},[23,1186,1152],{}," is silently cloned automatically",[135,1189,1191,1193,1194,1197,1198,1201,1202],{"className":1190},[138],[140,1192],{"disabled":142,"type":143}," Only ",[23,1195,1196],{},"retries"," fails, since ",[23,1199,1200],{},"u32"," isn't ",[23,1203,901],{},[193,1205,1206,1208,1223],{},[196,1207,198],{},[200,1209,1210,1212,1213,1166,1215,1169,1217,1173,1219,1176,1221,1179],{},[203,1211,205],{}," B — Fails to compile — ",[23,1214,1165],{},[23,1216,147],{},[23,1218,1172],{},[23,1220,147],{},[23,1222,1152],{},[200,1224,1225,220,1227,1229,1230,1232,1233,1235,1236,1238,1239,1241,1242,1244,1245,1248,1249,1251,1252,1254,1255,1257,1258,1261,1262,1265,1266,1269,1270,435,1272,1274,1275,1277,1278,1280,1281,1283,1284,1286],{},[203,1226,219],{},[23,1228,223],{}," moves every non-overridden, non-",[23,1231,901],{}," field out of ",[23,1234,147],{}," field-by-field. Since ",[23,1237,1165],{}," (a ",[23,1240,669],{},") isn't ",[23,1243,901],{},", it's moved into ",[23,1246,1247],{},"updated.name",", leaving ",[23,1250,147],{}," partially moved — the compiler then rejects ",[23,1253,1152],{}," (and any whole-",[23,1256,147],{}," use) with \"value borrowed here after partial move\" \u002F \"use of moved value.\" ",[203,1259,1260],{},"Idiom:"," the fix is to ",[23,1263,1264],{},".clone()"," the field explicitly if you need both, e.g. ",[23,1267,1268],{},"name: base.name.clone(), ..base",". Note ",[23,1271,1196],{},[23,1273,1200],{}," (",[23,1276,901],{},"), so overriding it doesn't move anything — but that's irrelevant since it was overridden, not taken from ",[23,1279,147],{},", and D wrongly claims only ",[23,1282,1196],{}," is the problem when the real issue is ",[23,1285,1165],{},". A and C both falsely assume Rust performs implicit borrowing\u002Fcloning here.",[14,1288,1289,1307,1345],{},[18,1290,1292,1293,1296,1297,1299,1300,1303,1304,670],{"id":1291},"q9-calling-rectanglesquare0-on-a-tuple-free-square-associated-function-that-builds-rectangle-width-size-height-size-what-happens-with-size-0","Q9. Calling ",[23,1294,1295],{},"Rectangle::square(0)"," on a tuple-free ",[23,1298,577],{}," associated function that builds ",[23,1301,1302],{},"Rectangle { width: size, height: size }"," — what happens with ",[23,1305,1306],{},"size = 0",[130,1308,1310,1316,1322,1335],{"className":1309},[133],[135,1311,1313,1315],{"className":1312},[138],[140,1314],{"disabled":142,"type":143}," Compile error — struct fields cannot be zero",[135,1317,1319,1321],{"className":1318},[138],[140,1320],{"disabled":142,"type":143}," Panics at runtime because zero-area rectangles are invalid",[135,1323,1325,1327,1328,1330,1331,1334],{"className":1324},[138],[140,1326],{"disabled":142,"type":143}," Compiles and runs fine, producing a ",[23,1329,543],{}," with ",[23,1332,1333],{},"width: 0, height: 0","; nothing about the type prevents degenerate values",[135,1336,1338,1340,1341,1344],{"className":1337},[138],[140,1339],{"disabled":142,"type":143}," Returns ",[23,1342,1343],{},"None"," since the rectangle would be empty",[193,1346,1347,1349,1358],{},[196,1348,198],{},[200,1350,1351,1353,1354,1330,1356,1334],{},[203,1352,205],{}," C — Compiles and runs fine, producing a ",[23,1355,543],{},[23,1357,1333],{},[200,1359,1360,1362,1363,1365,1366,1368,1369,1372],{},[203,1361,219],{}," Plain struct fields with primitive types like ",[23,1364,1200],{}," accept any value in their range, including ",[23,1367,438],{}," — the struct itself enforces no domain invariant unless you add validation logic (e.g., a fallible constructor returning ",[23,1370,1371],{},"Result",", or a newtype with private fields and a checked constructor). This is an edge case worth internalizing: structs alone don't guarantee \"sensible\" values. A, B, and D all invent validation that plain struct construction does not perform.",[14,1374,1375,1379,1470,1521],{"language":16},[18,1376,1378],{"id":1377},"q10-whats-the-pitfall-in-this-destructuring-pattern-using-struct-update-syntax-combined-with-a-method-call","Q10. What's the pitfall in this destructuring pattern using struct update syntax combined with a method call?",[28,1380,1381],{"language":16},[31,1382,1384],{"className":33,"code":1383,"language":16,"meta":35,"style":35},"struct Session { token: String, expires_in: u32 }\nimpl Session {\n    fn refreshed(self, new_token: String) -> Session {\n        Session { token: new_token, ..self }\n    }\n}\n",[23,1385,1386,1409,1417,1443,1461,1466],{"__ignoreMap":35},[39,1387,1388,1390,1393,1396,1398,1400,1403,1405,1407],{"class":41,"line":42},[39,1389,266],{"class":45},[39,1391,1392],{"class":56}," Session",[39,1394,1395],{"class":49}," { token",[39,1397,63],{"class":45},[39,1399,66],{"class":56},[39,1401,1402],{"class":49},", expires_in",[39,1404,63],{"class":45},[39,1406,495],{"class":56},[39,1408,801],{"class":49},[39,1410,1411,1413,1415],{"class":41,"line":102},[39,1412,452],{"class":45},[39,1414,1392],{"class":56},[39,1416,470],{"class":49},[39,1418,1419,1421,1424,1426,1428,1431,1433,1435,1437,1439,1441],{"class":41,"line":520},[39,1420,475],{"class":45},[39,1422,1423],{"class":56}," refreshed",[39,1425,75],{"class":49},[39,1427,486],{"class":87},[39,1429,1430],{"class":49},", new_token",[39,1432,63],{"class":45},[39,1434,66],{"class":56},[39,1436,489],{"class":49},[39,1438,492],{"class":45},[39,1440,1392],{"class":56},[39,1442,470],{"class":49},[39,1444,1445,1448,1450,1452,1455,1457,1459],{"class":41,"line":559},[39,1446,1447],{"class":56},"        Session",[39,1449,1395],{"class":49},[39,1451,63],{"class":45},[39,1453,1454],{"class":49}," new_token, ",[39,1456,125],{"class":45},[39,1458,486],{"class":87},[39,1460,801],{"class":49},[39,1462,1463],{"class":41,"line":808},[39,1464,1465],{"class":49},"    }\n",[39,1467,1468],{"class":41,"line":836},[39,1469,562],{"class":49},[130,1471,1473,1483,1499,1510],{"className":1472},[133],[135,1474,1476,1478,1479,1482],{"className":1475},[138],[140,1477],{"disabled":142,"type":143}," This never compiles — ",[23,1480,1481],{},"..self"," cannot be used inside a method",[135,1484,1486,220,1488,1490,1491,1494,1495,1498],{"className":1485},[138],[140,1487],{"disabled":142,"type":143},[23,1489,486],{}," is consumed by value here, so ",[23,1492,1493],{},"refreshed"," can only be called once per ",[23,1496,1497],{},"Session"," instance (each call requires ownership, matching the \"produce a new session, discard the old\" intent)",[135,1500,1502,220,1504,1507,1508],{"className":1501},[138],[140,1503],{"disabled":142,"type":143},[23,1505,1506],{},"expires_in"," is silently reset to ",[23,1509,438],{},[135,1511,1513,220,1515,1518,1519],{"className":1512},[138],[140,1514],{"disabled":142,"type":143},[23,1516,1517],{},"new_token"," must implement ",[23,1520,901],{},[193,1522,1523,1525,1535],{},[196,1524,198],{},[200,1526,1527,628,1529,1490,1531,1494,1533,1498],{},[203,1528,205],{},[23,1530,486],{},[23,1532,1493],{},[23,1534,1497],{},[200,1536,1537,1539,1540,1542,1543,1545,1546,1548,1549,1551,1552,1554,1555,1557,1558,1560,1561,1563,1564,1566,1567,1569,1570,1572],{},[203,1538,219],{}," Taking ",[23,1541,486],{}," by value is a deliberate, idiomatic choice for \"transform and replace\" APIs — it deliberately prevents the caller from accidentally reusing the stale ",[23,1544,1497],{}," after refreshing, since the old value is moved into the method and never returned. ",[23,1547,1481],{}," inside the struct literal simply copies\u002Fmoves ",[23,1550,486],{},"'s remaining fields (",[23,1553,1506],{},") into the new instance, exactly like the earlier update-syntax examples, just now with ",[23,1556,486],{}," as the base. A is false — ",[23,1559,1481],{}," is valid anywhere a struct literal appears, including method bodies. C is fabricated; ",[23,1562,1506],{}," carries over unchanged. D is false — ",[23,1565,1517],{}," is being moved in directly as a field value, not through update syntax, and ",[23,1568,669],{}," need not be ",[23,1571,901],{}," for that.",[14,1574,1575,1589,1633],{},[18,1576,1578,1579,307,1582,1585,1586,670],{"id":1577},"q11-two-struct-types-happen-to-have-identical-field-names-and-types-struct-metersf64-and-struct-feetf64-what-happens-if-you-try-let-m-meters-feet30","Q11. Two struct types happen to have identical field names and types: ",[23,1580,1581],{},"struct Meters(f64)",[23,1583,1584],{},"struct Feet(f64)",". What happens if you try ",[23,1587,1588],{},"let m: Meters = Feet(3.0);",[130,1590,1592,1601,1614,1627],{"className":1591},[133],[135,1593,1595,1597,1598,1600],{"className":1594},[138],[140,1596],{"disabled":142,"type":143}," Compiles fine — both wrap an ",[23,1599,274],{},", so they're structurally interchangeable",[135,1602,1604,1606,1607,307,1610,1613],{"className":1603},[138],[140,1605],{"disabled":142,"type":143}," Compile error — Rust's type system is nominal, not structural; ",[23,1608,1609],{},"Meters",[23,1611,1612],{},"Feet"," are distinct types even with identical layout",[135,1615,1617,1619,1620,1623,1624],{"className":1616},[138],[140,1618],{"disabled":142,"type":143}," Compiles, but ",[23,1621,1622],{},"m.0"," will be ",[23,1625,1626],{},"0.0",[135,1628,1630,1632],{"className":1629},[138],[140,1631],{"disabled":142,"type":143}," Only fails at runtime with a type-mismatch panic",[193,1634,1635,1637,1646],{},[196,1636,198],{},[200,1638,1639,1641,1642,307,1644,1613],{},[203,1640,205],{}," B — Compile error — Rust's type system is nominal, not structural; ",[23,1643,1609],{},[23,1645,1612],{},[200,1647,1648,1650,1651,307,1653,1655,1656,1658,1659,1662],{},[203,1649,219],{}," This is precisely the value of the newtype pattern: even though ",[23,1652,1609],{},[23,1654,1612],{}," are both single-field tuple structs wrapping ",[23,1657,274],{}," with identical memory layout, Rust treats them as unrelated types by name\u002Fdeclaration, not by shape. ",[203,1660,1661],{},"Safety:"," this is what prevents unit-confusion bugs (e.g., mixing up meters and feet) at compile time rather than in production. A describes structural typing, which languages like TypeScript use but Rust does not. C and D invent runtime behaviors that don't apply — this is caught at compile time, full stop, with \"mismatched types.\"",[14,1664,1665,1669],{"language":16},[18,1666,1668],{"id":1667},"q12-what-happens-when-a-structs-field-is-itself-a-reference-and-the-structs-owner-tries-to-outlive-the-borrowed-data","Q12. What happens when a struct's field is itself a reference and the struct's owner tries to outlive the borrowed data?",[28,1670,1671,1674,1682,1684,1737,1777,1778,1886,1955,2079,2185,2264,2370],{"language":16},[200,1672,1673],{},"struct Highlight\u003C'a> { text: &'a str }",[31,1675,1680],{"className":1676,"code":1678,"language":1679},[1677],"language-text","::\n\n- [ ] The struct owns a copy of the text, so no lifetime issue exists\n- [ ] Nothing shown here fails by itself, but any attempt to construct a `Highlight` whose `text` outlives the source string is rejected at compile time — the struct can never outlive the data it borrows\n- [ ] This struct definition itself fails to compile\n- [ ] `'a` defaults to `'static` automatically\n\n\u003Cdetails>\n\u003Csummary>Show Answer\u003C\u002Fsummary>\n\n**Answer:** B — Nothing shown here fails by itself, but any attempt to construct a `Highlight` whose `text` outlives the source string is rejected at compile time — the struct can never outlive the data it borrows\n\n**Explanation:** The struct definition itself is valid Rust (tying the struct's lifetime parameter to the borrowed field), but any use site that tries to keep a `Highlight` alive longer than the `&str` it points into will be rejected — this is the struct-holds-a-reference case that ties directly back to explicit lifetime annotations. A is wrong — `&'a str` is a borrow, not an owned copy. C is wrong — the definition compiles fine on its own. D is false — lifetimes on struct fields are never silently defaulted to `'static`; they must be satisfied by whatever data is actually borrowed.\n\n\u003C\u002Fdetails>\n::\n\n::question-wrapper{language=\"rust\"}\n### Q13. `#[derive(Debug)]` is added to a struct containing a field of a type that doesn't implement `Debug`. What happens?\n\n::code-wrapper{language=\"rust\"}\n```rust\nstruct RawSocket(*mut u8);\n#[derive(Debug)]\nstruct Connection {\n    id: u32,\n    socket: RawSocket,\n}\n","text",[23,1681,1678],{"__ignoreMap":35},[200,1683,69],{},[130,1685,1687,1700,1715,1728],{"className":1686},[133],[135,1688,1690,1692,1693,1696,1697],{"className":1689},[138],[140,1691],{"disabled":142,"type":143}," It compiles; ",[23,1694,1695],{},"derive(Debug)"," silently skips fields that don't implement ",[23,1698,1699],{},"Debug",[135,1701,1703,1705,1706,1708,1709,164,1711,1714],{"className":1702},[138],[140,1704],{"disabled":142,"type":143}," It fails to compile — ",[23,1707,1695],{}," requires every field's type to also implement ",[23,1710,1699],{},[23,1712,1713],{},"RawSocket"," doesn't",[135,1716,1718,1720,1721,1724,1725],{"className":1717},[138],[140,1719],{"disabled":142,"type":143}," It compiles but panics the first time ",[23,1722,1723],{},"{:?}"," is used on a ",[23,1726,1727],{},"Connection",[135,1729,1731,1733,1734,1736],{"className":1730},[138],[140,1732],{"disabled":142,"type":143}," Raw pointers always implement ",[23,1735,1699],{},", so this compiles without issue",[193,1738,1739,1741,1748],{},[196,1740,198],{},[200,1742,1743,1745,1746,1736],{},[203,1744,205],{}," D — Raw pointers always implement ",[23,1747,1699],{},[200,1749,1750,1752,1753,1756,1757,1760,1761,1763,1764,1766,1767,1769,1770,1772,1773,1776],{},[203,1751,219],{}," This is a genuine gotcha: ",[23,1754,1755],{},"*mut u8"," (and other raw pointer types) ",[245,1758,1759],{},"do"," implement ",[23,1762,1699],{}," in the standard library, printing as a hex address — so ",[23,1765,1713],{},", despite looking like it wraps something exotic, actually satisfies the derive requirement here, and the whole thing compiles fine. The broader rule that trips people up is real (B describes the general case correctly for types that truly lack ",[23,1768,1699],{},", such as function-pointer-heavy or certain FFI-opaque types), but it doesn't apply to this specific example because raw pointers are one of the types that do implement ",[23,1771,1699],{},". A is false — ",[23,1774,1775],{},"derive"," never silently skips fields; it fails the whole derive if any field is missing a required impl. C invents a runtime failure where the real failure (when it does happen) is a compile error, not a panic.","\n::",[14,1779,1780,1788,1836],{},[18,1781,1783,1784,1787],{"id":1782},"q14-what-does-rectangle-width-10-defaultdefault-require-in-order-to-compile","Q14. What does ",[23,1785,1786],{},"Rectangle { width: 10, ..Default::default() }"," require in order to compile?",[130,1789,1791,1801,1821,1830],{"className":1790},[133],[135,1792,1794,1796,1797,1800],{"className":1793},[138],[140,1795],{"disabled":142,"type":143}," Nothing extra — ",[23,1798,1799],{},"Default::default()"," always works for any struct",[135,1802,1804,220,1806,1808,1809,1812,1813,1816,1817,1820],{"className":1803},[138],[140,1805],{"disabled":142,"type":143},[23,1807,543],{}," must implement (or derive) the ",[23,1810,1811],{},"Default"," trait, since ",[23,1814,1815],{},"..Default::default()"," calls ",[23,1818,1819],{},"Rectangle::default()"," to supply the other fields",[135,1822,1824,220,1826,1829],{"className":1823},[138],[140,1825],{"disabled":142,"type":143},[23,1827,1828],{},"width"," must be removed from the struct entirely",[135,1831,1833,1835],{"className":1832},[138],[140,1834],{"disabled":142,"type":143}," This syntax is only valid for tuple structs",[193,1837,1838,1840,1852],{},[196,1839,198],{},[200,1841,1842,628,1844,1808,1846,1812,1848,1816,1850,1820],{},[203,1843,205],{},[23,1845,543],{},[23,1847,1811],{},[23,1849,1815],{},[23,1851,1819],{},[200,1853,1854,1856,1857,1859,1860,1862,1863,1866,1867,1869,1870,1872,1873,1875,1876,1879,1880,1882,1883,1885],{},[203,1855,219],{}," Type inference figures out that ",[23,1858,1799],{}," here must produce a ",[23,1861,543],{}," (because it's used as the base in a ",[23,1864,1865],{},"Rectangle { .. }"," literal), then calls ",[23,1868,1819],{},". If ",[23,1871,543],{}," doesn't implement ",[23,1874,1811],{}," (via ",[23,1877,1878],{},"#[derive(Default)]"," or a manual ",[23,1881,452],{},"), this fails to compile with a trait-bound error, not silently falling back to zeroed memory. A is wrong for exactly that reason. C misunderstands the syntax — ",[23,1884,1828],{}," stays as an explicit override. D is false — struct update syntax works with named-field structs like this example, not just tuple structs.",[14,1887,1888,1898,1929],{},[18,1889,1891,1892,1895,1896,670],{"id":1890},"q15-when-designing-a-public-api-why-is-it-generally-best-practice-to-keep-struct-fields-private-and-expose-associated-function-constructors-plus-accessor-methods-rather-than-making-all-fields-pub","Q15. When designing a public API, why is it generally best practice to keep struct fields ",[203,1893,1894],{},"private"," and expose associated-function constructors plus accessor methods, rather than making all fields ",[23,1897,965],{},[130,1899,1901,1907,1913,1923],{"className":1900},[133],[135,1902,1904,1906],{"className":1903},[138],[140,1905],{"disabled":142,"type":143}," Private fields are faster at runtime than public ones",[135,1908,1910,1912],{"className":1909},[138],[140,1911],{"disabled":142,"type":143}," Private fields let you enforce invariants at construction\u002Fmutation time and change the internal representation later without breaking downstream code",[135,1914,1916,1918,1919,1922],{"className":1915},[138],[140,1917],{"disabled":142,"type":143}," Rust requires private fields for ",[23,1920,1921],{},"#[derive(Debug)]"," to work",[135,1924,1926,1928],{"className":1925},[138],[140,1927],{"disabled":142,"type":143}," Public fields are not allowed on structs that implement any trait",[193,1930,1931,1933,1938],{},[196,1932,198],{},[200,1934,1935,1937],{},[203,1936,205],{}," B — Private fields let you enforce invariants at construction\u002Fmutation time and change the internal representation later without breaking downstream code",[200,1939,1940,220,1942,1944,1945,1947,1948,1951,1952,1954],{},[203,1941,219],{},[203,1943,1260],{}," this is the standard \"encapsulation\" argument applied to Rust — a ",[23,1946,965],{}," field can be set to any value satisfying its type from anywhere, bypassing any validation logic, and it locks the struct's internal layout into your public API forever (a semver-breaking change to alter later). Exposing a constructor (",[23,1949,1950],{},"Config::new(...)"," returning ",[23,1953,1371],{}," if validation can fail) and getters\u002Fsetters keeps the door open for future changes. A is false — there's no runtime cost difference between public and private field access. C and D are fabricated constraints.",[14,1956,1957,1961,1998,2034],{"language":16},[18,1958,1960],{"id":1959},"q16-a-method-needs-to-mutate-one-field-of-a-struct-but-the-struct-is-large-and-cloning-it-would-be-wasteful-which-receiver-is-idiomatic","Q16. A method needs to mutate one field of a struct but the struct is large and cloning it would be wasteful. Which receiver is idiomatic?",[28,1962,1963],{"language":16},[31,1964,1966],{"className":33,"code":1965,"language":16,"meta":35,"style":35},"struct Cache { entries: Vec\u003CString>, hits: u64 }\n",[23,1967,1968],{"__ignoreMap":35},[39,1969,1970,1972,1975,1978,1980,1983,1986,1988,1991,1993,1996],{"class":41,"line":42},[39,1971,266],{"class":45},[39,1973,1974],{"class":56}," Cache",[39,1976,1977],{"class":49}," { entries",[39,1979,63],{"class":45},[39,1981,1982],{"class":56}," Vec",[39,1984,1985],{"class":49},"\u003C",[39,1987,669],{"class":56},[39,1989,1990],{"class":49},">, hits",[39,1992,63],{"class":45},[39,1994,1995],{"class":56}," u64",[39,1997,801],{"class":49},[130,1999,2001,2010,2019,2028],{"className":2000},[133],[135,2002,2004,220,2006,2009],{"className":2003},[138],[140,2005],{"disabled":142,"type":143},[23,2007,2008],{},"fn record_hit(self)"," — take by value, mutate, then the caller must reassign the return value",[135,2011,2013,220,2015,2018],{"className":2012},[138],[140,2014],{"disabled":142,"type":143},[23,2016,2017],{},"fn record_hit(&mut self)"," — mutate the field directly through a mutable borrow",[135,2020,2022,220,2024,2027],{"className":2021},[138],[140,2023],{"disabled":142,"type":143},[23,2025,2026],{},"fn record_hit(&self)"," — using interior mutability is always the right default even without needing it",[135,2029,2031,2033],{"className":2030},[138],[140,2032],{"disabled":142,"type":143}," Clone the struct, mutate the clone, and return it, leaving the original untouched",[193,2035,2036,2038,2044],{},[196,2037,198],{},[200,2039,2040,628,2042,2018],{},[203,2041,205],{},[23,2043,2017],{},[200,2045,2046,220,2048,220,2050,2052,2053,122,2056,2059,2060,2063,2064,2067,2068,2071,2072,2074,2075,2078],{},[203,2047,219],{},[203,2049,1260],{},[23,2051,689],{}," is exactly the tool for \"mutate in place without giving up ownership or reallocating\" — it's the standard, zero-cost choice for methods like ",[23,2054,2055],{},"push",[23,2057,2058],{},"insert",", or counters like ",[23,2061,2062],{},"hits += 1",". A works but forces every caller into an awkward ",[23,2065,2066],{},"cache = cache.record_hit();"," pattern for no benefit when in-place mutation is possible. C is a common overcorrection — reaching for ",[23,2069,2070],{},"RefCell","\u002Finterior mutability by default adds runtime borrow-checking overhead and complexity that plain ",[23,2073,689],{}," avoids when you already have exclusive access. D wastes an entire clone of ",[23,2076,2077],{},"entries: Vec\u003CString>"," just to increment a counter — needless allocation and copying.",[14,2080,2081,2097,2143],{},[18,2082,2084,2085,2087,2088,2091,2092,1951,2094,670],{"id":2083},"q17-reviewing-a-pr-you-see-a-builder-struct-where-every-setter-method-consumes-and-returns-self-by-value-fn-with_retriesmut-self-n-u32-self-selfretries-n-self-why-is-this-the-idiomatic-pattern-for-builders-rather-than-using-mut-self-returning-mut-self","Q17. Reviewing a PR, you see a builder struct where every setter method consumes and returns ",[23,2086,486],{}," by value: ",[23,2089,2090],{},"fn with_retries(mut self, n: u32) -> Self { self.retries = n; self }",". Why is this the idiomatic pattern for builders, rather than using ",[23,2093,689],{},[23,2095,2096],{},"&mut Self",[130,2098,2100,2109,2125,2137],{"className":2099},[133],[135,2101,2103,2105,2106,2108],{"className":2102},[138],[140,2104],{"disabled":142,"type":143}," It isn't idiomatic — ",[23,2107,689],{}," chaining is strictly better and should be preferred",[135,2110,2112,1539,2114,2116,2117,2120,2121,2124],{"className":2111},[138],[140,2113],{"disabled":142,"type":143},[23,2115,486],{}," by value enables fluent, chainable one-liner construction (",[23,2118,2119],{},"Builder::new().with_retries(3).with_timeout(5).build()",") that can be built as a single expression, including from a function's tail-return position, without needing an intermediate ",[23,2122,2123],{},"let mut"," binding",[135,2126,2128,220,2130,2132,2133,2136],{"className":2127},[138],[140,2129],{"disabled":142,"type":143},[23,2131,486],{},"-by-value is required because ",[23,2134,2135],{},"Self"," cannot appear as a return type otherwise",[135,2138,2140,2142],{"className":2139},[138],[140,2141],{"disabled":142,"type":143}," There's no difference between the two approaches in any circumstance",[193,2144,2145,2147,2158],{},[196,2146,198],{},[200,2148,2149,2151,2152,2116,2154,2120,2156,2124],{},[203,2150,205],{}," B — Taking ",[23,2153,486],{},[23,2155,2119],{},[23,2157,2123],{},[200,2159,2160,220,2162,2164,2165,2168,2169,2172,2173,2175,2176,2178,2179,2181,2182,2184],{},[203,2161,219],{},[203,2163,1260],{}," the by-value builder pattern is idiomatic specifically because it composes into a single expression — useful in contexts like a function's implicit return (",[23,2166,2167],{},"fn make() -> Config { Config::builder().with_retries(3).build() }",") where you can't easily have a ",[23,2170,2171],{},"let mut b = ...;"," statement. The ",[23,2174,689],{}," -> ",[23,2177,2096],{}," chaining style also works and avoids repeated moves, but requires an owned ",[23,2180,2123],{}," binding up front and doesn't work as cleanly in expression position, which is why by-value chaining is the more commonly seen idiom for builders. A overstates it as strictly better in all cases — both are valid, with different tradeoffs. C is a fabricated restriction; ",[23,2183,2135],{}," return types work fine with any receiver. D dismisses a real, meaningful ergonomic difference.",[14,2186,2187,2199,2230],{},[18,2188,2190,2191,2194,2195,2198],{"id":2189},"q18-whats-the-best-practice-reason-to-prefer-an-associated-function-like-pointorigin-point-over-requiring-callers-to-write-point-x-00-y-00-directly-everywhere","Q18. What's the best-practice reason to prefer an associated function like ",[23,2192,2193],{},"Point::origin() -> Point"," over requiring callers to write ",[23,2196,2197],{},"Point { x: 0.0, y: 0.0 }"," directly everywhere?",[130,2200,2202,2210,2216,2222],{"className":2201},[133],[135,2203,2205,220,2207,2209],{"className":2204},[138],[140,2206],{"disabled":142,"type":143},[23,2208,2197],{}," is not valid syntax",[135,2211,2213,2215],{"className":2212},[138],[140,2214],{"disabled":142,"type":143}," It centralizes the \"what does a default\u002Fspecial-case value look like\" decision in one place, and keeps working even if you later make the fields private or add new fields",[135,2217,2219,2221],{"className":2218},[138],[140,2220],{"disabled":142,"type":143}," Associated functions run faster than struct literals",[135,2223,2225,2227,2228],{"className":2224},[138],[140,2226],{"disabled":142,"type":143}," It's required for the struct to implement ",[23,2229,901],{},[193,2231,2232,2234,2239],{},[196,2233,198],{},[200,2235,2236,2238],{},[203,2237,205],{}," B — It centralizes the \"what does a default\u002Fspecial-case value look like\" decision in one place, and keeps working even if you later make the fields private or add new fields",[200,2240,2241,220,2243,2245,2246,2249,2250,2253,2254,2256,2257,2260,2261,2263],{},[203,2242,219],{},[203,2244,1260],{}," this is the same encapsulation argument as constructors generally — if ",[23,2247,2248],{},"Point"," gains a third field ",[23,2251,2252],{},"z: f64"," later, every call site that manually wrote ",[23,2255,2197],{}," breaks, but a single ",[23,2258,2259],{},"Point::origin()"," definition only needs updating once. It also keeps working if fields become private. A is false — direct struct-literal syntax works fine when fields are public. C is a fabricated performance claim; both compile to equivalent code. D is unrelated — ",[23,2262,901],{}," is an independent derive, unaffected by whether you use a literal or a constructor function.",[14,2265,2266,2280,2326],{},[18,2267,2269,2270,2273,2274,2276,2277,670],{"id":2268},"q19-in-review-someone-suggests-changing-fn-totalself-f64-which-sums-two-fields-to-instead-take-self-by-value-arguing-its-simpler-why-would-that-be-a-worse-choice-for-a-getter-style-method-used-inside-a-loop-like-for-item-in-items-sum-itemtotal","Q19. In review, someone suggests changing ",[23,2271,2272],{},"fn total(&self) -> f64"," (which sums two fields) to instead take ",[23,2275,486],{}," by value, arguing \"it's simpler.\" Why would that be a worse choice for a getter-style method used inside a loop like ",[23,2278,2279],{},"for item in &items { sum += item.total(); }",[130,2281,2283,2293,2312,2320],{"className":2282},[133],[135,2284,2286,2288,2289,2292],{"className":2285},[138],[140,2287],{"disabled":142,"type":143}," It would fail to compile in a ",[23,2290,2291],{},"for"," loop",[135,2294,2296,1539,2298,2300,2301,2304,2305,2307,2308,2311],{"className":2295},[138],[140,2297],{"disabled":142,"type":143},[23,2299,486],{}," by value would move ",[23,2302,2303],{},"item"," out of the collection on the first iteration (or, since ",[23,2306,2303],{}," here is ",[23,2309,2310],{},"&Item",", force an extra deref\u002Fclone), which is unnecessary overhead and friction for a method that never needs to consume the value",[135,2313,2315,220,2317,2319],{"className":2314},[138],[140,2316],{"disabled":142,"type":143},[23,2318,274],{}," cannot be returned from a by-value method",[135,2321,2323,2325],{"className":2322},[138],[140,2324],{"disabled":142,"type":143}," There is no difference — both compile to identical machine code",[193,2327,2328,2330,2342],{},[196,2329,198],{},[200,2331,2332,2151,2334,2300,2336,2304,2338,2307,2340,2311],{},[203,2333,205],{},[23,2335,486],{},[23,2337,2303],{},[23,2339,2303],{},[23,2341,2310],{},[200,2343,2344,220,2346,2348,2349,2351,2352,2355,2356,2358,2359,2362,2363,2365,2366,2369],{},[203,2345,219],{},[203,2347,1260],{}," the general principle is: only take ",[23,2350,486],{}," by value when the method genuinely needs ownership (e.g., transforming into a different type, or a builder's terminal ",[23,2353,2354],{},"build()","). A pure read like summing fields for a total should use ",[23,2357,697],{},", so it can be called repeatedly on borrowed items (as in ",[23,2360,2361],{},"for item in &items",") without consuming anything. Switching to by-value ",[23,2364,486],{}," would, at minimum, require cloning ",[23,2367,2368],{},"Item"," at each call site to satisfy ownership, adding needless allocation\u002Fcopy overhead in a hot loop. A is false — it can be made to compile (with clones), it's just wasteful. C is a fabricated restriction on return types. D dismisses a real, meaningful runtime cost difference.",[14,2371,2372,2379,2412],{},[18,2373,2375,2376,2378],{"id":2374},"q20-a-struct-has-grown-to-8-fields-and-a-refactor-wants-to-add-a-9th-while-preserving-all-existing-call-sites-that-construct-it-with-a-full-field-list-no-update-syntax-whats-the-best-practice-tradeoff-to-flag-in-review","Q20. A struct has grown to 8 fields, and a refactor wants to add a 9th while preserving all existing call sites that construct it with a full field list (no ",[23,2377,125],{}," update syntax). What's the best-practice tradeoff to flag in review?",[130,2380,2382,2388,2398,2406],{"className":2381},[133],[135,2383,2385,2387],{"className":2384},[138],[140,2386],{"disabled":142,"type":143}," Nothing to flag — adding a field to a struct is always backward compatible",[135,2389,2391,2393,2394,2397],{"className":2390},[138],[140,2392],{"disabled":142,"type":143}," Adding a field is a breaking change for any code using exhaustive struct-literal construction (every call site must add the new field, or the struct should switch to a builder\u002Fconstructor pattern, or mark itself ",[23,2395,2396],{},"#[non_exhaustive]"," for external consumers)",[135,2399,2401,2403,2404],{"className":2400},[138],[140,2402],{"disabled":142,"type":143}," Fields can only be added if the struct implements ",[23,2405,1811],{},[135,2407,2409,2411],{"className":2408},[138],[140,2410],{"disabled":142,"type":143}," This requires bumping the struct to a tuple struct instead",[193,2413,2414,2416,2423],{},[196,2415,198],{},[200,2417,2418,2420,2421,2397],{},[203,2419,205],{}," B — Adding a field is a breaking change for any code using exhaustive struct-literal construction (every call site must add the new field, or the struct should switch to a builder\u002Fconstructor pattern, or mark itself ",[23,2422,2396],{},[200,2424,2425,220,2427,2429,2430,2433,2434,2436,2437,2439,2440,2442,2443,2445],{},[203,2426,219],{},[203,2428,1260],{}," unlike adding a method (which is always additive and non-breaking), adding a field to a struct that callers construct with ",[23,2431,2432],{},"StructName { a, b, c, ... }"," literal syntax breaks every one of those call sites unless they use ",[23,2435,1815],{}," or ",[23,2438,223],{}," update syntax to fill in the gap. This is exactly why widely-consumed public structs either expose a constructor\u002Fbuilder instead of public fields, or are annotated ",[23,2441,2396],{}," so external crates are forced to use a constructor and can't exhaustively list fields at all. A is the naive assumption that bites maintainers of public crates. C invents an unrelated requirement — ",[23,2444,1811],{}," doesn't automatically shield existing literals. D is a non-sequitur; switching to a tuple struct doesn't address the exhaustive-construction problem and loses named-field readability.",[2447,2448,2449],"style",{},"html pre.shiki code .svdQ7, html code.shiki .svdQ7{--shiki-default:#D73A49;--shiki-github-dark:#F97583}html pre.shiki code .ssxIu, html code.shiki .ssxIu{--shiki-default:#24292E;--shiki-github-dark:#E1E4E8}html pre.shiki code .sIsaT, html code.shiki .sIsaT{--shiki-default:#6F42C1;--shiki-github-dark:#B392F0}html pre.shiki code .sJ6F3, html code.shiki .sJ6F3{--shiki-default:#032F62;--shiki-github-dark:#9ECBFF}html pre.shiki code .snvgF, html code.shiki .snvgF{--shiki-default:#005CC5;--shiki-github-dark:#79B8FF}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .github-dark .shiki span {color: var(--shiki-github-dark);background: var(--shiki-github-dark-bg);font-style: var(--shiki-github-dark-font-style);font-weight: var(--shiki-github-dark-font-weight);text-decoration: var(--shiki-github-dark-text-decoration);}html.github-dark .shiki span {color: var(--shiki-github-dark);background: var(--shiki-github-dark-bg);font-style: var(--shiki-github-dark-font-style);font-weight: var(--shiki-github-dark-font-weight);text-decoration: var(--shiki-github-dark-text-decoration);}",{"title":35,"searchDepth":102,"depth":102,"links":2451},[2452,2454,2455,2456,2458,2460,2462,2464,2466,2468,2469,2471],{"id":20,"depth":520,"text":2453},"Q1. Given struct User { name: String, age: u8, active: bool }, what does struct update syntax do here?",{"id":253,"depth":520,"text":254},{"id":358,"depth":520,"text":359},{"id":448,"depth":520,"text":2457},"Q4. What's the essential difference between these two impl block items?",{"id":661,"depth":520,"text":2459},"Q5. Which method receiver should fn describe(&self) -> String use if it only needs to read fields and return a new owned String?",{"id":738,"depth":520,"text":2461},"Q6. What does calling a method that takes self (by value, not &self) do to the original variable?",{"id":961,"depth":520,"text":2463},"Q7. What visibility do struct fields have by default, inside their own module, if declared without a pub keyword?",{"id":1026,"depth":520,"text":2465},"Q8. What happens when you use struct update syntax where the base struct contains a non-Copy field that you don't override?",{"id":1291,"depth":520,"text":2467},"Q9. Calling Rectangle::square(0) on a tuple-free square associated function that builds Rectangle { width: size, height: size } — what happens with size = 0?",{"id":1377,"depth":520,"text":1378},{"id":1577,"depth":520,"text":2470},"Q11. Two struct types happen to have identical field names and types: struct Meters(f64) and struct Feet(f64). What happens if you try let m: Meters = Feet(3.0);?",{"id":1667,"depth":520,"text":1668},"md",{},"\u002Frust\u002F11-structs",{"title":5,"description":35},"rust\u002F11-structs","uoqtWBfqPq9klBF9_vgiNJWmIG7UvmEa7wCcvv1VxQs",1787335398386]