Feature Request: Hashed Based Assertion

[bitwise via Digitalmars-d]

On Thursday, 26 November 2015 at 11:12:07 UTC, tcak wrote:
> I brought this topic in "Learn" a while ago, but I want to talk 
> about it again.
>
> You are in a big team or working with a big code base. APIs are 
> being defined/modified, configuration constants are 
> defined/modified, structures are defined/modified for data.
>
> You are coding on business logic side, and relying everything 
> based on current APIs, configuration, and data structures. A 
> part of codes have been updated on API side, but you are not 
> aware of it, or time has passed, and you assume that your code 
> will work properly. Nobody would be checking every single part 
> of business logic line by line.
>
> On runtime, you will get unexpected results, and lose some hair 
> till finding where the problem is. Also finding expected 
> results on a long running processes would cause much more 
> trouble.
>
> ---
>
> What I do currently is that: I calculate the hash of API code 
> (function, configuration, etc together) with a hash function, 
> and store it where the API is defined as a constant.
>
> public enum HASH_OF_THIS_API = 0x1234;
>
> // Hash is calculated from here
> public void my_api_function(){}
>
> public enum my_api_constant = 5;
> // till here
>
> Then wherever I use that API, I insert a "static assert( 
> HASH_OF_THIS_API == 0x1234 );".
>
> Whoever modifies the API, after the modification, calculates 
> the most recent code's hash value and updates the constant. 
> This allows compiler to warn the business logic programmer 
> about changes on API codes. So, changing parts can be reviewed 
> and changes are made if required.
>
> ---
>
> The feature request part comes here: It is possible that API 
> programmer forgets to update the hash value in the code. Also, 
> comments in the code shouldn't affect the hash value. 
> Automation is required on compile-time, so the compiler 
> automatically calculates the hash value of code, and it can be 
> read on compile-time. Hence, no constant is required to store 
> the hash value.
>
> What is needed is to be able to bind a hash value to any block 
> with a name.

I'm wondering if a diff tool could be somehow combined with a 
parser to create a list of functions/symbols which may have 
experienced behavioural changes between versions of dmd. What I'm 
suggesting is a diff tool which is aware of a symbol's 
dependancies so that even if a function body wasn't changed, its 
dependant symbols could be checked as well.

If such a tool existed, it could be ran against each new release 
of dmd, and produce a comma separated list of functions that may 
have experienced behavioural changes. With that list in hand, one 
could then simply grep for each symbol in their own repository 
each time they upgrade dmd.

I hearby place this idea in the public domain ;)

    Bit