Proposal for improving pure situation,

[HansOlsson]

To ensure that current MSL is valid and that users can update.

Closes #3719

Note that in addition to the changes in the issue reordered the items and changed "must" to "should" for the deprecated semantic, and clearly indicated that the exception is the deprecated case.
(Having a "must"-requirement and then have exceptions for it just seems wrong.)

[henrikt-ma]

The way I read the proposal, a tool should generate a deprecation warning for every function not explicitly declared pure or impure. This makes it hard to make sense of the "normally" rule in the beginning.

Am I getting the intention right if I think the goal is to:

• Lack of explicit purity of an external function is deprecated.
• For a function not declared impure, it is deprecated to call an external function not declared pure. (Hence, making the impure of an external function explicit will address one deprecation warning without leading to new ones.)
• For a function without explicit purity, it is deprecated to call any function declared impure. (Making the impure of an external function explicit will cause an error if called from a function explicitly declared pure.)
• A function is assumed impure in the following cases (applied recursively):
  • It is declared impure
  • It is an external function without explicit purity
  • It calls another function assumed impure
• (A function not assumed impure is assumed pure.)

What I am trying to capture above is that the deprecation rules have only to do with the explicit declaration of functions as pure or impure, whereas the reasoning about impure behavior is based on rules which are formulated so that they make sense regardless of deprecated (lack of) purity declaration.

[HansOlsson]

The way I read the proposal, a tool should generate a deprecation warning for every function not explicitly declared pure or impure.

That wasn't the intention, the new semantics was only intended to kick in if:

• The calling function is declared without pure or impure
• They call an external function that is not pure (directly or indirectly).

That is a bad combination, and shouldn't be common.
(An impure function should only be called in an impure function (except for ...)).
However, it did occur in MSL - when people started to declare the external functions as impure, and missed the callers due to lack of testing in tools.

The proposed semantics ensure that MSL 4.1.0 is kind of valid. And even more importantly, it also avoids breaking user libraries/models in the same way that rely on those functions in MSL.

[HansOlsson]

The way I read the proposal, a tool should generate a deprecation warning for every function not explicitly declared pure or impure.

That wasn't the intention, the new semantics was only intended to kick in if:

• The calling function is declared without pure or impure
• They call an external function that is not pure (directly or indirectly).

This has now been clarified even further.