Bumping since this is especially pressing now that I'm trying to put together a sort of standard library.
A "normal" #include would allow implementing special inheritance (especially mixins, interfaces) and very large macros in much cleaner ways.
If there's legacy support concerns, a new instruction (eg "#finclude") could be used for this, with the same functionality as #include (except without the check for whether it's already been included).

Another helpful thing along these lines would be a command to define/insert a block:


After all, it's a little strange to write macros with semicolons and curly brackets and insert it into code that uses the off-sides rule.

Edit: Found another use case for #including multiple times, long pre-processor instructions. For example, there might be multiple places in the compilation process where one might want to check the BYOND version and throw warnings/errors. Unless there's any more undocumented operators and instructions i'm not aware of, the pre-processor cannot handle even simple compounds of its commands, much less complex ones (this is probably because it uses a very simple parser, which does not have proper statement separators/terminators or block markers, and can't distinguish between # appearing as an operator or as part of a word). This means the best solution becomes putting the desired instructions in a file and #include-ing it: but that means this can only be done once due to the "include only once" limitation.

Wild Bill Bartok wrote:

Bumping again, I suppose.

This would be extremely useful, and it doesn't seem overly difficult to implement on the compiler side of things (to say the least). Plus it wouldn't break anything or slow anything down, so there's that.

Bumping things doesn't mean they'll get looked at, considered or even implemented. I've been trying that on a few requests for a couple of years now, some are more involved than others and some are simple edits the the IDE....