You want isset() and this has nothing to do with the specification.

bullshit - isset() don't work when a variable is defined and contains NULL, you should read your own documentation

[harry@srv-rhsoft:/mnt/data/downloads]$ php test.php
[harry@srv-rhsoft:/mnt/data/downloads]$ cat test.php
<?php
 $x = NULL;
 if(isset($x))
 {
  echo "defined\n";
 }
?>

> how [...] do you test if a variable is defined with the isset() behavior
> saying no if the value is NULL

  isset($var) && !is_null($var)

@cmb The question is how to detect whether a variable is defined, but null.

@op You correctly surmised that there is no (obvious) way to do this. Could you please describe why you consider this to be necessary? Checking whether a *simple* variable is defined is, as far as I can tell, useless in any case. If you want to check whether an array key exists (and is null) you can use array_key_exists. Similarly for objects there is property_exists.

RTFM: isset($var) && !is_null($var) is nonsense because  because when isset() is true it can't be NULL - just because the design mistake that isset() returns false when the value is NULL

if(isset($nicht_definiert) || is_null($nicht_definiert)) is the only way to emulate a sane isset() behavior but raises a warning when the variable is undefined

so you CAN NOT write code without warnings in case if you ned to know if a variable is undefined 

* in case of the value NULL it is not undefined
* isset() has a pervert behavior returning false
* if the variable is undefined is_null() raises a warning

and the next time befor you close a bug or recommend something like "isset($var) && !is_null($var)" while everybody reading the docs knows that it won't work jsut read the docs

> Could you please describe why you consider this to be necessary?

well, why does isset() exists with your logic? - it is necessary because the isset() behavior is braindead return false in case of NULL - if i want that behavior i would just use empty()

the whole purpose of isset() is to check if a variable is defined
the whole purpose if is_null() is to work around broken isset() behavior
and no - put a @ in front is not a clean coding style

> well, why does isset() exists with your logic?

Practically speaking, it exists so you can write isset($array['key']). This is the primary use-case for isset(). Writing isset($array), which implies that you do not know if a variable exists, sounds rather fishy to me, thus my inquiring as to your particular use-case that is supposed to require distinguishing between undefined and null for simple variables.

practically speaking the only fishy is a programming language with such illogical inconsistency not following the rule of least suprise and that *is* a bug which you can't discuss away with "i don't know why someone would write code like this" - that someone can expect a sane and logical behavior

> it exists so you can write isset($array['key'])

but it don't work relieable because in case of the key existing but NULL as value it gives back false which is pure bullshit - frankly speaking my breath was away as your answers implied isset() in case of a array-key and a simple variable again behaves different, at least that is not the case - it's the same way wrong  



[harry@srv-rhsoft:~]$ cat test.php
<?php
$x = array();
$x['a'] = NULL;
if(isset($x['a']))
{
 echo "DEFINED\n";
}
else
{
 echo "UNDEFINED\n";
}

$y = NULL;
if(isset($y))
{
 echo "DEFNINED\n";
}
else
{
 echo "UNDEFINED\n";
}

Indeed, isset() behaves the same for array keys and object properties. I was merely pointing out that for these usages there are alternatives like array_key_exists(), which will return true even if the value is null.

If this does not satisfy your use-case, you're out of luck. The behavior of isset() will not change. The behavior of is_null() can not change either, as it is an ordinary function, not a language construct.

> If this does not satisfy your use-case

you refuse to understand that such pervert behavior is not a matter of a use-case - it's a matter of a clean and expectable language behavior

i don't have a usecase, i was just asked today what isset() in case of NULL gives back and i answered true just because of logical thinking that the variable is defined and so set

> The behavior of is_null() can not change either, 
> as it is an ordinary function, not a language construct

and how does that matter in the context of not idiotically throw warnings in case of a undefined variable instead just return false since it don't have the value NULL and so make it at least *possible* to distinct between a undefined variable or NULL as value

Harald, please reconsider your attitude. Claiming that the behavior
of isset is braindead, while it obviously works well for millions
of programmers, and even ranting and cursing, is certainly
unrewarding. :)

If you really consider it necessary to change the behavior or, more
realistically, introduce a new language construct, feel free to
propose a respective RFC; see the instructions in the Wiki on how
to do so[1].

[1] <https://wiki.php.net/rfc/howto>

well, you can't seriously claim wrong behavior correct just beause millions of programmers learned to deal with the inconsistent und unexpected behavior left and right all over the programming language

and BTW you at your own did not understand the PHP behavior, otherwise you would not have reommended "isset($var) && !is_null($var)" while "isset() && is_null()" is just impossible and so the && construct makes no sense

There is a Stack Overflow question discussing this at length here: http://stackoverflow.com/q/418066/157957

If you are dynamically defining array keys or object properties, array_key_exists and property_exists allow you to check their existence regardless of value. Dynamically defining actual variables is possible, but universally worse than using an array or object container, so does not require language support.

This leaves only the case where you don't know if a variable has been *initialised*; since an uninitialised variable is considered to have the value null, a variable set to null is considered the same as one which hasn't been initialised. This is consistent, well-documented, and reasonable behaviour.

It may not be the behaviour you would LIKE, but insulting people on a public bug tracker is not going to convince them a change is needed.

> since an uninitialised variable is considered to 
> have the value null, a variable set to null is 
> considered the same as one which hasn't been 
> initialised. This is consistent

bullshit - how can the behavior below callend consistent and how can anything you said above be true with that braindead behavior throwing a warning in once case when you pretend a unitialized variable has the value NULL

[harry@srv-rhsoft:/mnt/data/downloads]$ php test.php
NULL

Notice: Undefined variable: y in /mnt/data/downloads/test.php on line 7
NULL

[harry@srv-rhsoft:/mnt/data/downloads]$ cat test.php
<?php
 $x = NULL;
 if(is_null($x))
 {
  echo "NULL\n";
 }
 if(is_null($y))
 {
  echo "NULL\n";
 }
?>

Bob pointed out that it's possible to use get_defined_vars() in combination with array_key_exists() to check whether a variable is defined but null.