Skript: Functions are not executed if any of the values is Null

[bi0qaw]

Functions are not executed if any of the values passed to them are null.
Example:

function foo(v1: object, v2: object):
    broadcast "message"

foo does not send any message if you execute it like this:

command /test:
    trigger:
        foo({_v1}, {_v2})

It does not work either with:

command /test:
    trigger:
        foo(true, {_v2})

[bensku]

Any errors in console?

[bi0qaw]

Nothing

[TheBentoBox]

I've noticed this before as well on my live server, which is running dev25, so I don't believe it to be a new issue either.

[HYPExMon5ter]

I’ve had this problem as well

[Pikachu920]

this isn't a bug, its certainly intended behavior (i.e. why should scripters have to deal with null checks). if you reallllly want, you can pass skript-mirror's null ref as a null value

[TheBentoBox]

Even if it was intended at the time of implementation it was a really bad choice and should be changed. What if you're passing some variable value into the function and want to do something within the function if it isn't set (as opposed to checking if it's set every time you call the function)? You literally just can't do that right now because you can't pass in an unset (null) variable. This is especially bad given that there's no warning sent anywhere (i.e. console) to let you know a called function didn't run; you can write a perfectly good function with a normal design pattern and then spend ages debugging why it's not working when it's due to the function silently failing to even run in the first place because a value is null.

[Pikachu920]

seeing as skript doesn't even have something to specifically represent null, it was a great decision. There's tons of things in skript that fail silenty.

[Snow-Pyon]

I don't feel like this makes sense either way, and changing this behavior wouldn't break any scripts so it's better being labeled as bug.

[Syst3ms]

This behaviour is defined here

[Pikachu920]

You can't just go changing stuff like this willy nilly. The only good solution would be a way to accept if a parameter should accept null in the function definition, like function name(victim: player?) for example

[bi0qaw]

@Pikachu920 It is a huge problem because it is inconsistent with Skript's default behaviour. Look at this example:

function test(worldname: string):
    set {_world} to world {_worldname}
    broadcast "%{_world}%"

command /test:
    trigger:
        set {_world} to world {_worldname}
        broadcast "%{_world}%"

If I execute /test I will get a "<none>" message. If I execute test({_v}) without setting {_v} I will not get any message whatsoever. Expressions in Skript accept unset variables by default. Functions should behave the same way. There is nothing "willy nilly" about it.

[Pikachu920]

Those are two different scenarios. If you wanted to compare closer, the code would look like this

function test(playername: string):
    set {_player} to name of ({_playername} parsed as a player)
    broadcast "%{_player}%"

command /test:
    trigger:
        set {_player} to name of ({_playername} parsed as a player)
        broadcast {_player}

and you wouldn't receive the broadcast in either case with an unset variable

Anyways, is anyone against the ? modifier to accept null values?

[bi0qaw]

I agree that you don't get any message in both cases. However, the command still continues to execute while the function doesn't.

Just add a little message at the end of the function and command in your script and you will see that one message is sent while the other is not.

function test(playername: string):
    set {_player} to name of ({_playername} parsed as a player)
    broadcast "%{_player}%"
    broadcast "test(): this is executed"

command /test:
    trigger:
        set {_player} to name of ({_playername} parsed as a player)
        broadcast {_player}
        broadcast "/test: this is executed"

[TheBentoBox]

I really honestly don't even see the argument here. The way it works currently is completely not intuitive and not intelligent and I'm not sure how it could be argued otherwise. When you call a function, it should get called. The plugin should not decide for you based on hidden conditions (which are not listed in the config or by a warning from the plugin) whether or not your function will run. If you pass in a null value, it is your responsibility as a programmer to handle that inside of the function; it is not the language's choice to ignore what you told it to do based on its own decisions. This is also not better or easier for new programmers. New programmers need things to be intuitive; this implementation is not intuitive, and it is not consistent with other programming languages where null can be passed in place of any type in a function and without the function call being ignored.

[Pikachu920]

There was a lengthy discussion about this in skript-chat and I think it was decided not to change this behavior immediately. There needs to be more talk about how skript deals with null everywhere

[bensku]

Went ahead and added config option for this, because a pull request to latest release spits out warnings if you try to circumvent this issue by putting stuff in parentheses (none to string "\").

Edit: Enabled by default, optional config option.

[Pikachu920]

shouldn't it be off by default to replicate the original behavior?

[bensku]

These are development releases, I expect people to test stuff when they update. The release notes have instructions for switching back to the old behaviour.

I'm also curious: how many people this change affected. The configuration option is in metrics, so we will soon find out.