I don't even know what this means :-)
We will soon put a page explaining more in the details the rational behind the question which is related to void-safety.
If you vote no to the above question, please put a rationale. We will put the rationale behind the question tomorrow.
Bertrand's article emphasizes the fact that 'attached' should be the default. No problem with that. But at work we are very far from having converted all our 20,000 Eiffel classes to void-safety. So keeping the possibility to override this default until all our classes are void-safe would be helpful. Not indispensable, but helpful.
After more thoughts I think that we can do without the option. We have to edit the class anyway when making it void-safe. So it's probably better to avoid confusion and use the standard settings right from the start.
Indeed, it is most likely that whenever you compile a class in void-safe mode some changes are required. So using only one way to set defaults will help code readability by making sure everything is consistent.
ETL appendix C deals with change. It suggests that change in a language feature should meet two conditions:
2. The implementors must provide a conversion mechanism for existing software.
Shouldn't that apply here?
Of course we will make sure that existing code still compiles but for new code, if the change is accepted, we will simply not allow changing the default attachment status.