Discussion: How to handle type annotations

[abingham]

As part of the language and the AST, type annotations are potentially subject to annotation. At the same time, it seems that nearly all mutations to type annotations will result in equivalent mutants; that is, they rarely have an effect that's detectable at runtime. There are, however, situations where mutations to type annotations can have a runtime effect; one example was demonstrated to me by @rob-smallshire.

Given all of this, we need to decide how CR will deal with type annotations.

Ignore them completely

One possibility is to simply ignore them completely. We could build this into the low-level AST visitor code, thereby treating it as a policy decision for the project. This has the downside of disallowing mutation of annotations in the cases where it might matter. On the upside, it's something we could change our mind about later.

Disable them by default but allow selected mutations

We could decide that mutation of annotations is disabled by default but that the user can select instances to be mutated. This would lend itself to some sort of interceptor-based approach as has been explored by @Alcolo47.

Enable them by default but allow selected disabling of mutation

This is just the complement of the last idea. It seems unlikely (to me) to be the right approach, but it's a possibility.

Others?

Maybe there are clever ways to manage these. Maybe, in fact, there are ways to integrate type annotations into a test suite, e.g. by running mypy over the code to look for violations, thereby making CR mutation of annotations more meaningful.

[boxed]

What is that example?

[abingham]

Unfortunately is from a client project that we can't (as far as I know) share, but it has to do with introspecting the type annotation at runtime in order to facilitate interfacing with another language (Java, I think). Of all the ways we considered to do this, it was the cleanest and most unsurprising...when trying to work with static languages, be a little static ourselves.

On Wed, Oct 9, 2019 at 6:41 PM Anders Hovmöller [email protected] wrote:

What is that example?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sixty-north/cosmic-ray/issues/479?email_source=notifications&email_token=AAATK6EDUQ7TXEZ5KDPWGKDQNYJVFA5CNFSM4I7CNZQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAYW2RQ#issuecomment-540110150, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAATK6F4PES7ZBYD3JOVVE3QNYJVFANCNFSM4I7CNZQA .

[boxed]

Ah. Yea that description is enough for me to understand the issue. We have something similar at work where we generate Elm code for data structure serialization between front end and backend that now uses dataclasses.