Y-Less

OK that MCVE might not be accurate. I just realised that all the ones I was seeing were used in `SYSREQ.C` in code that isn't itself called: ```c native MyHeapspace()...

For some reason I can't edit: ```pawn native MyHeapspace() = heapspace; stock NotUsed() { __emit(PUSH.C 0, SYSREQ.C MyHeapspace, STACK 4); } main() { } ```

https://github.com/pawn-lang/YSI-Includes/blob/d31e1916454e984bc927eee2102532ed25d5fa77/YSI_Internal/y_distribute.inc#L111-L130 https://github.com/pawn-lang/YSI-Includes/blob/b2993bdaed33642c3c48f94ed063eb84ef4c91f7/YSI_Visual/y_commands/impl.inc#L145-L148 Were this done, `__attribute__` or another function-like macro would be VASTLY preferable to `[[]]` for backwards-compatibility. It would be very easy to strip them in the old compiler...

Actually, it should really be `__Pragma` which would match the other new compiler symbols `__Pawn` and `__PawnBuild`.

Not that I like that naming scheme...

That's pretty much exactly what that means. Things in the compiler should be consistent, not named a dozen different ways.

Though I did mention somewhere else that as long as there is consistency, maybe `__PawnBuild` could be changed instead.

Plus the fact that `__Pawn` was in the original compiler only adds to its use as precedent.

OK, I see no reason why this should be different to `#pragma`; aAll the talk about what should be available to which is just IMHO a pointless complication. Or at...

> What should we use as delimiters for attributes - commas with optional whitespaces before/after them, as proposed initially Why would you delimit attributes? You can't do that with `#pragma`:...