unittest affects next unittest

[Era Scarecrow via Digitalmars-d-learn]

On Wednesday, 6 August 2014 at 17:42:02 UTC, Jonathan M Davis 
wrote:
> It wouldn't make sense to warn about that, because it could be 
> very legitimately be what the programmer wants to do. We can't 
> warn about anything that would be legitimate to have, because 
> it would force programmers to change their code to get rid of 
> the warning, even when the code was valid. So, while in most 
> cases, it might be a problem, we can't warn about it. But I do 
> think that the spec should be clearer about it.

  This is the similar problem to assignment inside if statements 
where it's easy to mistake and can cause problems later. I think 
it should warn, because the behavior although proper is a jarring 
difference from a class version of it.

  However to make the warning go away with 'yeah this is what i 
want so don't complain' a simple tag confirms while doubling as 
documentation for behavior would probably be enough. A short 
simple word probably wouldn't be enough for specific cases but 
something short... Maybe @shared_init or @propagates_statically, 
@static_assignment or something.

  Of course i don't want to litter the language with tags that 
aren't relevant except in certain obscure cases...