Contract error string generation is not implicitly @nogc

[tsbockman]

On Sunday, 4 September 2022 at 15:05:45 UTC, IGotD- wrote:
> Which make me wonder if the @nogc attribute is totally 
> unnecessary.
> ...
> Wouldn't it be better if we get an error like GCBohem.Allocate 
> symbol isn't found, the reason would be obvious.

One of the main motivators for avoiding the GC is to prevent low 
latency code from suffering the GC's "stop the world" pauses.

By operating at the function level, rather than the whole program 
level, `@nogc` can help write correct programs where latency 
tolerant code can use the GC, and low latency code can avoid it 
by running in separate threads that don't get stopped durring 
collections. Simply removing the GC entirely from a program 
forces everything to be `@nogc`, instead of just the most latency 
sensitive parts.

(Having said that, `@nogc` is a very incomplete and unsafe 
solution to this problem, since it doesn't make any attempt to 
prevent GC-using parts of the program from passing ownership of 
GC memory to `@nogc` threads through parameters or shared memory, 
nor does it prevent the use of modules with GC dependant module 
thread-local constructors.)