Question improvements

Author: postrational

questions/q107.yaml

@@ -30,27 +30,32 @@ expected_output:
 explanation: |-
   This question tests understanding of error handling with `Result`, the `map_err`
   combinator, and how collecting an iterator of `Result` values works.
-
+  
   The `parse_and_double` function attempts to parse a string into an `i32`,
   doubles it if successful, and transforms any parse error into a custom error
   message using `map_err`. The `map_err` combinator only executes when there's an
   `Err` variant, transforming the error type from `ParseIntError` to `String`.
-
+  
   When the code processes the inputs:
   1. `"5"` parses successfully to `5`, which is doubled to `10`, resulting in
-  `Ok(10)`
+     `Ok(10)`
   2. `"not a number"` fails to parse, producing an error that `map_err` transforms
-  into `Err("Parse failed: invalid digit found in string")`
+     into `Err("Parse failed: invalid digit found in string")`
   3. `"10"` is never processed
-
+  
   The key behavior is how `collect()` works with `Result` types. When collecting
   an iterator of `Result<T, E>` into `Result<Vec<T>, E>`, Rust implements
   short-circuit semantics: the collection stops at the first error encountered and
   returns that error immediately. This is an "all-or-nothing" pattern where either
   all operations succeed (producing `Ok(vec)`) or any failure causes the entire
   operation to fail with the first error.
-
+  
+  Note that if we collected into `Vec<Result<i32, String>>` instead, we would get
+  `[Ok(10), Err("Parse failed: invalid digit found in string"), Ok(20)]`, 
+  preserving all results. The choice of collection type determines whether errors
+  short-circuit or are collected alongside successes.
+  
   The key takeaway is that collecting `Result` values provides fail-fast
   semantics, which is useful for validation scenarios where partial success is not
   acceptable. The `map_err` combinator is valuable for adding context to errors or
-  converting between error types while preserving the success values unchanged.
+  converting between error types while preserving the success values unchanged.

questions/q162.yaml

@@ -5,7 +5,7 @@ question: |-
   fn main() {
       let paths = vec![
           "/usr/bin/../lib/file.so",
-          "relative/../path/to/file",
+          "relative/path/../file",
           "../../../etc/passwd",
           "normal/path/file.txt"
       ];
@@ -23,14 +23,14 @@ question: |-
 
   What does this code print?
 answers:
-- All print `Some("file")` as the parent directory name
-- First prints `Some("lib")`, second prints `Some("to")`, third prints `Some("etc")`, fourth prints `Some("path")`
-- First prints `Some("lib")`, second prints `Some("to")`, third prints `None`, fourth prints `Some("path")`
+- '`Some("file.so")`, `Some("file")`, `Some("passwd")`, `Some("file.txt")`'
+- '`Some("lib")`, `None`, `Some("etc")`, `Some("path")`'
+- '`Some("lib")`, `Some("..")`, `Some("etc")`, `Some("path")`'
 - All print `None` because parent directories cannot be determined from strings
 correct_answer: 1
 expected_output:
 - '/usr/bin/../lib/file.so: Some("lib")'
-- 'relative/../path/to/file: Some("to")'
+- 'relative/path/../file: None'
 - '../../../etc/passwd: Some("etc")'
 - 'normal/path/file.txt: Some("path")'
 explanation: |-
@@ -44,21 +44,16 @@ explanation: |-
   For `/usr/bin/../lib/file.so`, the parent is `/usr/bin/../lib`, and its file
   name component is `lib`, resulting in `Some("lib")`.
 
-  For `relative/../path/to/file`, the parent is `relative/../path/to`, and its
-  file name component is `to`, resulting in `Some("to")`.
+  For `relative/path/../file`, the parent is `relative/path/..`. The final
+  component `..` is not a valid file name, so the result is `None`.
 
-  For `../../../etc/passwd`, the parent is `../../../etc`. Rust's `Path` API
-  performs lexical (string-based) path operations. When extracting the file name
-  from `../../../etc`, it treats `etc` as a regular path component and returns
-  `Some("etc")`. The `..` components earlier in the path don't affect the file
-  name extraction of the final component.
+  For `../../../etc/passwd`, the parent is `../../../etc`, and its file name
+  component is `etc`, resulting in `Some("etc")`.
 
   For `normal/path/file.txt`, the parent is `normal/path`, and its file name
   component is `path`, resulting in `Some("path")`.
 
   The key takeaway is that Rust's `Path` API performs lexical operations without
   filesystem access or path normalization. The `file_name()` method extracts the
-  final component of a path as a string operation, treating each segment between
-  separators as a distinct component. Path components like `..` are treated as
-  regular components in the path string, and `file_name()` simply returns the last
-  non-empty component.
+  final component of a path, but returns `None` for special components like `..`
+  and `.`, as these are not considered valid file names.

questions/q343.yaml

@@ -0,0 +1,49 @@
+question: |-
+  ```rust
+  fn parse_and_double(s: &str) -> Result<i32, String> {
+      s.parse::<i32>()
+          .map(|n| n * 2)
+          .map_err(|e| format!("Parse failed: {}", e))
+  }
+
+  fn main() {
+      let inputs = vec!["5", "not a number", "10"];
+      
+      let result: Vec<Result<i32, String>> = inputs
+          .iter()
+          .map(|s| parse_and_double(s))
+          .collect();
+      
+      println!("{:?}", result);
+  }
+  ```
+  
+  What does this print?
+answers:
+- 'Err("Parse failed: invalid digit found in string")'
+- '[Ok(10), Err("Parse failed: invalid digit found in string"), Ok(20)]'
+- '[Ok(10), Err("Parse failed: invalid digit found in string")]'
+- 'Compilation error: cannot collect iterator of `Result` into `Vec<Result<_, _>>`'
+correct_answer: 1
+expected_output:
+- '[Ok(10), Err("Parse failed: invalid digit found in string"), Ok(20)]'
+explanation: |-
+  This question tests understanding of how collecting `Result` values into different
+  container types affects error handling behavior.
+  
+  When the code processes the inputs:
+  1. `"5"` parses successfully to `5`, doubled to `10`: `Ok(10)`
+  2. `"not a number"` fails to parse: `Err("Parse failed: invalid digit found in string")`
+  3. `"10"` parses successfully to `10`, doubled to `20`: `Ok(20)`
+  
+  When collecting into `Vec<Result<T, E>>`, all elements are processed without
+  short-circuiting. Each result is preserved in the vector, allowing both successes
+  and failures to coexist. All three results appear in the final vector.
+  
+  Note that if we collected into `Result<Vec<T>, E>` instead, the iterator would
+  short-circuit at the first error and return `Err("Parse failed: invalid digit
+  found in string")`, never processing the third element.
+  
+  The key takeaway is that the collection target type determines error handling:
+  `Vec<Result<T, E>>` collects all results including errors, while `Result<Vec<T>, E>`
+  provides fail-fast semantics that stop at the first error.