Isn't the original graphics.library written in C?
It's a mix of both, depending on the level of the function. The low-level stuff is in assembly, the higher and more complex operations are in C. Even then, the assembler stuff depends on some macros to provide at least some orientation on the program flow, i.e. the authors have used macros for conditions, loops and so on. The result is not quite as scary as "raw" assembler.
This specific function, and the region functions in particular, are in assembly. It's part of the low-level slice&dice operations that are commonly used between layers and graphics. Ideally, regions (like other layer-like structures) should be pooled, and hence NewRegion() should first try to take the region memory from a graphics specific pool, and recycle regions whenever possible.
Unfortunately, it's not what it does. If you want such pooling, PoolMem is there to help (it keeps memory pools for small fragments like struct Region, hence *may* help here).
Even more unfortunately, struct Region is documented, so *in principle* an appplication could create such a structure by AllocMem(), bypassing NewRegion() (bad idea!) or on the stack (also a bad idea!) Even then, such a change should be synchronized between graphics, layers, and code parts that re-implementent parts of layers & graphics (P96, cybergraphics, EGS...). Thus, in general, it is not such a good idea to change this lighthearted. It requires a pretty complete code review to understand the possible implications, and potentially a re-compile of graphics, layers, P96 and cybergraphics (in worst case).
One way or another, this example shows a constructional weakness of the whole AmigaOs: Too many internals have been documented, and the API is not always clear. Ideally, all "primitive objects" should have been left undocumented, or should have been equipped with clear constructor/destructor calls. struct Region is one of the "better" implementations by using such an API (partially), but the situation is much worse with other graphics primitivities, such as struct RastPort, struct Bitmap (big outch!), struct ViewPort (bigger outch!) or struct View. To avoid the many problems, V37 graphics jumps in circles and stores private data on the ViewPort not in the view port, but in the color map (even bigger outch!) loaded in the view port just to be able to extend it, and uses hoops such as GfxAssociate to be able to backwards-extend the gfx engine.
Gfx is a clear case of "how not to design a library". Intuition much better code from a software engineering perspective (there are clear structures and a relatively clean API). I guess this is all because gfx was written in a rush, for a deadline that was too close to allow a good implementation, and pretty much in an ad-hoc way.
Then again, all the region low-level calls should, instead of calling NewRegion() internally through gfx, go through the LVO instead. They don't do that, but probably should. Another outch.
