diff --git a/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki b/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki
index 1d1fa990..01f1fb8d 100644
--- a/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki
+++ b/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki
@@ -95,7 +95,7 @@ Upon creation, each element of the array will reference the same object; an obje
 
 ==Using the ''attribute'' keyword carefully==
 
-The keyword <code>attribute</code> should be used with some care. You might be tempted to think that it would be convenient or add an extra element of safety to use self-initializing attributes widely. And in a way, you would be correct. But you should also understand that there is a price to pay for using self-initializing attributes and stable attributes. It is that upon every access, an evaluation of the state of the attribute must be made. So, as a general rule, you should avoid using self-initializing attributes only for the purpose of lazy initialization.
+The keyword <code>attribute</code> should be used with some care. You might be tempted to think that it would be convenient or add an extra element of safety to use [[Void-safety: Background, definition, and tools#Self-initializing attributes|self-initializing attributes]] widely. And in a way, you would be correct. But you should also understand that there is a price to pay for using self-initializing attributes and stable attributes. It is that upon every access, an evaluation of the state of the attribute must be made. So, as a general rule, you should avoid using self-initializing attributes only for the purpose of lazy initialization.
 
 
 ==More about the ''attached syntax''==
diff --git a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki
index 2696c90c..91a42d69 100644
--- a/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki
+++ b/documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki
@@ -93,9 +93,18 @@ To construct equivalent objects of type <code>STRING</code> from those of type <
 <code>
     non_separate_string (a_sep_str: separate STRING): STRING
             -- Non-separate copy of `a_sep_str'
+        local
+            i: INTEGER
         do
             create Result.make_empty
-            across (1 |..| a_sep_str.count) as ic loop Result.append_character (a_sep_str [ic.item]) end
+            from
+                i := 1
+            until
+                i > a_sep_str.count
+            loop
+                Result.append_character (a_sep_str [i])
+                i := i + 1
+            end
         end
 </code>
 
@@ -110,8 +119,17 @@ The other alternate is to create a procedure that will print an object of type <
 <code>
     print_separate_string (a_sep_str: separate STRING)
             -- Print `a_sep_str' on standard output.
+        local
+            i: INTEGER
         do
-            across (1 |..| a_sep_str.count) as ic loop io.put_character (a_sep_str [ic.item]) end
+            from
+                i := 1
+            until
+                i > a_sep_str.count
+            loop
+                io.put_character (a_sep_str [i])
+                i := i + 1
+            end
         end
 </code>
 
@@ -122,9 +140,6 @@ Then you could use that procedure to output <code>my_separate_string</code>:
 </code>
 
 
-{{note|If you use the above solutions verbatim, you may have to set the Syntax setting to Provisional in your project settings to enable the iteration form of the loop construct. }}
-
-
 =Implementation dependent behavior=