Array typing
Bertrand Meyer
Dear Eiffel Users,
As a result of detailed discussions in Ecma TG4/TC49 (the Eiffel standard committee), a change was brought to typing rules starting with EiffelStudio 18.01. It is documented (see e.g. https://www.eiffel.org/doc/eiffel/Manifest%20array#Untyped_manifest_array) but a risk of backward incompatibility was spotted only recently. Here is a short description of the change and of possible issues, as well as a call for opinions.
Manifest arrays are arrays given by their elements, e.g. <<0, 1, 4, 9, 16, 25>>. Until this change manifest arrays were the only kind of expression whose type cannot be inferred from looking just at the expression. For example with fa: ARRAY [FIGURE] and the classic inheritance example, the assignment
s := <<a_circle, a_square>> -- [1]
was valid because the array elements’ types all conform to FIGURE. But the manifest array as such does not have a type. This is clearly an anomaly, which the standard fixes. If all the elements are of the same exact type T, INTEGER in the first example above, then the manifest array has type ARRAY [T]. If all element types conform to the type of one of them, it is used. Otherwise, you can specify a type, so that [1] must now be written
s := {ARRAY [FIGURE]} <<a_circle, a_square>> -- [2]
with the rule that all elements must have a conforming type.
As far as I know everyone agrees that this is how the language mechanism should be.
A consequence of the rule is that [1] will not compile any more; you must specify the type as in [2]. In addition an empty array <<>> is now of type ARRAY [NONE] and can no longer, for example, be assigned to s with the above type.
The problems mentioned cannot cause wrong behavior since they are detected at compile time. To minimize the migration effort, version 18.05 (to be released soon, probably renamed 18.06) will include, in the Code Analyzer, a check for those problems, with an option to update the code in each case by adding the appropriate {ARRAY [T]} qualification.
A case that is more damaging because code could compile but give a different behavior arises for programs that dynamically check the type of a manifest array, for example in an object test. For those we propose to add a warning, with an option to treat it as an actual error for full protection.
We have considered offering a compilation option that would preserve the previous behavior (context-sensitive typing, as in [1] above). Upon reflection, we have decided against it, on the argument that it would simply delay reckoning and in fact make the problem worse in the future if users start combining code using the old and new rules.
If you disagree with this policy we would like to hear from you.
-- Bertrand Meyer
Bertrand Meyer
The documentation page I cited, https://www.eiffel.org/doc/eiffel/Manifest%20array#Untyped_manifest_array, needs more details; it will be updated in the next couple of days.
-- BM
Bertrand Meyer
The page is up to date now (although still subject to checking).
Eric Bezault
> The problems mentioned cannot cause wrong behavior since they are
> detected at compile time. To minimize the migration effort, version
> 18.05 (to be released soon, probably renamed 18.06) will include, in the
> Code Analyzer, a check for those problems, with an option to update the
> code in each case by adding the appropriate {ARRAY [T]} qualification.
>
> A case that is more damaging because code could compile but give a
> different behavior arises for programs that dynamically check the type
> of a manifest array, for example in an object test. For those we propose
> to add a warning, with an option to treat it as an actual error for full
> protection.
behavior), will there be a "Fix" button associated with the warning
(or error) so that we can also add the appropriate {ARRAY [T]}
qualification at a click of a button to get the old behavior?
--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com