The confusing error message is a known issue, see #744. While it is true it is initalized to $nil when you declare the var without giving it a value you can't actually use it:

> var x~
> x
Exception: bad value: command must be callable or string containing slash, but is nil
[tty 55], line 1: x

A var name ending in a tilde is a function (or command if you prefer) and must be a lambda. You also can't assign a string to it:

> x~ = echo
Exception: wrong type: need nil, got string
[tty 56], line 1: x~ = echo

@gergelyk Thanks, this is an interesting edge case. Maybe the initial value for $x~ should be changed to $nop~...

@krader1961, even though x~ set to $nil is not callable, it is still usable. E.g. I can imagine:

var callback~
# some code here which may set `callback~`
# some code here which may clear `callback~`
if (is $callback~ $nil) { echo "Nothing to do!" } else { $callback~ }

@gergelyk, That's an interesting use case. I'm inclined to agree with @xiaq's proposal that the initial value be changed to $nop~ rather than special-case $nil. If you need to distinguish between code that might assign$nop~ and an uninitialized state you can always use a unique sentinel value:

> var none~ = { }
> var callback~ = $none~
# some code here which may set `callback~`
# some code here which may clear `callback~`
if (is $callback~ $none~) { echo "Nothing to do!" } else { $callback~ }

Yup, I agree. Proposal of @xiaq sounds reasonable.