Functions with zero arguments are improperly rejected

[exodustx0]

trafficstars

asar 1.90
function Foo() = 42

This produces error: (Einvalid_param_name): Invalid parameter name. [function Foo() = 42]. The cause is nsplit() weirdly returning the input string if the key is not found in it, rather than nothing at all. The input string, here, is empty, but nsplit() still returns a pointer to it. createuserfunc(), however, expects nsplit() to return a nullptr in this case, and since it doesn't get one, it tries validating the empty arguments string with confirmname(), which fails.

[p4plus2]

This should have a better error returned, or perhaps it should work outright. There was debate on whether functions with zero arguments should be allowed as there are multiple other ways to represent constants already (defines and static assignments). I'm open to opinion on this.

I'm in favor of a better error message and moving on. But if there is a strong use case or has some formatting advantage in not opposed.

[exodustx0]

I'm indifferent on this. I prefer a quirk-free feature set, but I also understand the desire to not have too many ways to achieve the same thing.

[trillllian]

imo it's kinda hypocritical to have a builtin function that takes 0 args while banning such constructs in user-defined functions

and even besides that, i think it should be allowed just for consistency

[exodustx0]

Hadn't thought of the builtin functions; in that case, I definitely think this should be allowed yeah.