Strictness of check aliases that derive from the same check

[zmughal]

The spec currently allows for aliases for the checks. This means that one may have two checks that both refer to the use of INT for different purposes. These checks will not help when something using those checks gets mixed up. Some examples of what this reminds me of is this discussion Joel Spolsky had about Apps Hungarian which talks about variables that are prefixed with rw (for row) and col (for column). Both are ints, but of different kinds of things. In the case of what Microsoft was using at the time, the compiler would not help with catching this, but it would at least look wrong. As this example looking at Ada points out, a typedef would not help there (C++ programmers would probably use things like enum and struct).

Is this something that would be in scope or would the best practice be to bless them so the values can not interact without some sort of casting (e.g., an unbless, Acme::Damn::damn() ) mechanism? Interestingly enough, that Ada post also gives an example of tainted strings.

[happy-barney]

don't need to use bless. This is definitely past MVP, but implementation wise, when transferring contract information with value, it should be stored as pointer to contract definition (for caching). Then it will either perform sufficiently enough as well as solve this problem - which should be opt-in behaviour.