Make functions a compile time construct on @strict

[vurvdev]

No overriding

Overriding functions at runtime is no longer a thing on @strict. It's rare, odd dynamic behavior that shouldn't really be a thing. Function objects will fulfill their purpose in the future.

@strict

function test() {}

function test() {} # ERROR!

It gives a warning without @strict for backwards compatibility.

Compile time

Like events, functions on @strict will now be compile time constructs, so it doesn't matter if they're inside an event tick() {} loop or something. The function will just be created once when the chip is compiled.

Basically: they will be cheaper to call and create. I raised the cost of calling functions on non-@strict, but the base cost is still 10 ops (will likely be lowered in the future).

Breaking Change to String Calls

Since they will be compile time constructs, string calls to userfunctions won't work on @strict (will get a "no such function" error). This could be reverted while keeping the perf boost from calling, but the cost of creating the function will still exist.

I think it is a worthwhile break since stringcalls should hopefully be made obsolete soon with function objects.

[Denneisk]

<--- Didn't read the first section of this PR

I think as a useful median between first class functions, functions names/signatures should be able to be overwritten. That shouldn't be a problem in a future where you could do Function = function(Args)[Type]{...}, Function = function(SameArgTypes)[SameType]{...}.

# library.txt
function void table:myLibraryFunc() {
    error("This is a stub! Define it in your code!")
}

.........
# file.txt
#include library.txt

function void table:myLibraryFunc() {
    print(This)
}

e.g., I wanted to create a library in E2 that works best with function references but to do so would require disabling @strict with this change, which isn't ideal, so my idea was to instead have it call one function that the user implements. I guess I could also simply not define it but it'll produces errors everywhere in the library.

[vurvdev]

<--- Didn't read the first section of this PR

I think as a useful median between first class functions, functions names/signatures should be able to be overwritten. That shouldn't be a problem in a future where you could do Function = function(Args)[Type]{...}, Function = function(SameArgTypes)[SameType]{...}.

# library.txt
function void table:myLibraryFunc() {
    error("This is a stub! Define it in your code!")
}

.........
# file.txt
#include library.txt

function void table:myLibraryFunc() {
    print(This)
}

e.g., I wanted to create a library in E2 that works best with function references but to do so would require disabling @strict with this change, which isn't ideal, so my idea was to instead have it call one function that the user implements. I guess I could also simply not define it but it'll produces errors everywhere in the library.

Either the library should define table:myLibraryFunc() or the function should be taken as a callback to another function.

[Denneisk]

Either the library should define table:myLibraryFunc() or the function should be taken as a callback to another function.

Actually, maybe a better solution, if you could add UDFs to #ifdef then this could be mitigated without adding overriding.

[vurvdev]

Either the library should define table:myLibraryFunc() or the function should be taken as a callback to another function.

Actually, maybe a better solution, if you could add UDFs to #ifdef then this could be mitigated without adding overriding.

Yeah, which would require removing overriding / "runtime" functions. I'm ofc open to that even if I think #ifdef should probably be scrapped in favor of a more general #if in the future

[vurvdev]

Should be merged after #2829 for the people currently using stringcalls and @strict for whatever reason