From 0ce37429b7523dcb5bbf48c9aca229d77da44d93 Mon Sep 17 00:00:00 2001
From: halw <halw@abb3cda0-5349-4a8f-a601-0c33ac3a8c38>
Date: Sun, 1 Aug 2010 15:42:36 +0000
Subject: [PATCH] Clarification added to rule for formal generic parameters.

Author:halw
Date:2010-08-01T15:42:36.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@646 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
---
 .../void-safety-background-definition-and-tools.wiki | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki b/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki
index 968d1b7c..9c55ef5d 100644
--- a/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki
+++ b/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki
@@ -249,9 +249,15 @@ What do we know about the void-safety of <code>x</code> ?
 
 In the case of the <code>INTEGER</code> derivation above, we know <code>x</code> is safe because <code>INTEGER</code> is an expanded type. But often types like <code>EMPLOYEE</code> will be reference types which could be void at run time.
 
-So for a class like <code>C [G]</code> containing a declaration <code>x: G</code> :
-* <code>G</code> is considered detachable and any class will work for an actual generic parameter
-* Application of features to <code>x</code> must include verification of attachment (CAPs, attached syntax, etc)
+'''For a class like <code>C [G]</code>, <code>G</code> is considered detachable'''. As a result, because of the [[Void-safety: Background, definition, and tools#Rule for conformance|rule for conformance]], any class will work for an actual generic parameter. That means that both of the following are valid generic derivations:
+
+<code>
+    my_detachable_string_derivation: C [detachable STRING]
+
+    my_attached_string_derivation: C [attached STRING]
+</code>
+
+If <code>C</code> contains a declaration <code>x: G</code>, the application of features to <code>x</code> must include verification of attachment (CAPs, attached syntax, etc).
 
 Constrained genericity can be used to create generic classes in which the generic parameter represents an attached type. If class <code>C</code> had been defined as: 
 <code>