Do we want the Null-Coalescing Operator in Autoit?

[Exit]

Hello developer community,

before I open a feature request, I wanted to ask for the general opinion on this topic.
I like to use the Null-Coalescing operator (??) in my PHP scripts and miss him in Autoit.
In addition to the ternary operator (? :), this operator is part of the group of Conditional Assignment Operators.

$x = expr1 ?? expr2
The value of $x is expr1 if expr1 exists, and is not NULL.
If expr1 does not exist, or is NULL, the value of $x is expr2.

With this operator you can, for example, easily assign default values.

Do we want the Null-Coalescing Operator in Autoit?

What is your opinion on this topic?

Thanks in advance
Exit

[mikell]

In AutoIt, "Null evaluates only to Null, still in mathematical operations this keyword has value of 0, and as string it has no value (empty string)" (helpfile, keyword Null)
So this should be the same :  $x = $expr1 ? $expr1 : $expr2
If not, I foresee problems with the definition of "null", non-existent variables, etc 

[jchd]

Or it would make sense to switch to a three-valued logic like in SQL with identical rules but that would be a major internal change, hence unlikely to ever happen.

I'm among those who think that this would be a good thing. For instance, Local $x is currently meaning Local $x = "" in AutoIt but making it mean Local $x = Null would make full sense: I declare a new variable $x having no assigned value yet. The closest meaning to SQL Null is "I don't know", which is a good representation of many real-world circumstances, in programming and elsewhere as well!

SQL coalesce() is pretty much the same as a generalized ternary operator which can be applied to a set of elements, returning the first non-null value.

[JockoDundee]

2 hours ago, jchd said:

Or it would make sense to switch to a three-valued logic like in SQL with identical rules but that would be a major internal change, hence unlikely to ever happen.

Yes, but ANSI or not?

In other words, does NULL = NULL ?

[Nine]

Is that a Coalescing Operator for dummies or for nulls ?

[JockoDundee]

53 minutes ago, Nine said:

Is that a Coalescing Operator for dummies or for nulls ?

[jchd]

9 hours ago, JockoDundee said:

In other words, does NULL = NULL ?

Let's see: SELECT NULL = NULL; returns null
Similarly: SELECT case NULL when NULL then 23 else 9 end; returns 9
And it's easy to see why: a something which value noone knows can't be equal to another something which doesn't have a value either.
On the contrary: SELECT NULL IS NULL; returns 1
Same as: SELECT NULL ISNULL; returns 1

[Skysnake]

Personally I would enjoy seeing a NULL usage conforming to SQL. In my tiny corner of the universe it would make sense.

 

[JockoDundee]

On 8/23/2021 at 12:15 AM, jchd said:

And it's easy to see why: a something which value noone knows can't be equal to another something which doesn't have a value either.

I agree with the first half - comparing a unknown value with another unknown value should not be equal.  But, things that don’t have a value are different from being unknown.

For instance if, in an employee table if DOB is Null.  
I’m less convinced about Apt# being Null.

Apt# being null in two different rows likely indicates “doesn’t live in an apt”

DOB being null doesn’t indicate “not born”.

Still, I think some form of Null is definitely useful.  I experimented with making a Global Const $Null = -(MAX_INT), but it didn’t feel right.

Edited August 24, 2021 by JockoDundee

[jchd]

You're trying to infer a logical meaning depending on field semantic.

On 8/24/2021 at 7:19 PM, JockoDundee said:

Apt# being null in two different rows likely indicates “doesn’t live in an apt”

No, that means "I don't know" and it's the same when you don't know whether the guy lives in a flat or whether this information is just missing or invalid.

On 8/24/2021 at 7:19 PM, JockoDundee said:

DOB being null doesn’t indicate “not born”.

Correct, that means "I don't know". Zillions of people on Earth have no idea of their own DOB. Many don't even know their approximate age!

Date of death being Null would mean "we don't know whether this person is still alive since we han't been informed of his/her death". When the row is read, with DOD = Null, the person might well be actually dead 30 second or months ago, but the information hasn't made it into the database yet.

[JockoDundee]

1 hour ago, jchd said:

No, that means "I don't know" and it's the same when you don't know whether the guy lives in a flat or whether this information is just missing or invalid.

So then, in the case of say a graduationDate column, if generating a report that lists people who haven’t graduated, you would not advise select name from people where graduationDate=Null  ?

Instead would you add a boolean graduated ?  And then check constraints so they don’t get out of sync?

[jchd]

This is a schema design question. Having Null for non-graduates is perfectly consistent in some cases. But then you need ... where graduationDate is Null because using = Null won't work.

In this and many other cases, you can regard Nulls as "we don't have this information, or the provided value is invalid". When I write "I don't know" there is not a way to say "maybe, maybe not" with some vague notion of probability between both.

Having a separate boolean column is redondant in this case. If for instance you can have students graduated or not in more than one domain, then this isn't correct.

[JockoDundee]

5 hours ago, jchd said:

using = Null won't work.

Yes, I would agree.  I was copying you 

9 hours ago, jchd said:

When the row is read, with DOD = Null

 

5 hours ago, jchd said:

This is a schema design question.

Yes, agree.  I guess I’ve never been totally happy with nulls, although thankful to have them.  I don’t like how they are not transitive, although again I understand the argument.

Anyway, I think AutoIt would be better with some form of them, besides null=0.

[Earthshine]

i think it should behave the way C# does

but this won't work for AutoIt, it would always just resolve to the value of 0 anyway. but it could be a type that just has a value of zero

Edited August 26, 2021 by Earthshine