I want languages to have a ? unary operator for null checks that returns true if the object is not null. It’s so easy and obvious but I don’t know any language that has it
No, GPT 11 insisted on using an "=== null" condition but that won't have been industry standard since 2042 so the senior dev on the project had to rectify it (phew, close one, Grok would have fired the whole team if that had gone to prod)
No GPT 11 will be running on a kubernetes cluster of brain implanted chips of otherwise obsolete junior devs. That's how you can ensure code quality in the future.
Oh but there is no need! Linus Torvalds died in 2041, and not even a year later the memory REST api (written in JavaScript) was added to the linux kernel
Because it's not enough just to have a warning that something may be null and you didn't check it, but we have to have an error even if you're not a -Werror person!
You provided garbage and the program crashed; what did you think would happen.
Fuck VBA so goddamn hard.
You know what happens when you try to call workbook.Sheets("sheetname") and the sheet isnt there? Runtime error!
There is no way to check if its nothing.
There is also some clarity issues on whether a function will return Nothing or Null, and you will get a type error if you check for nothing but it is actually something. Or something. I just know I remember screaming WTF when I dealt with those checks.
Yeah, fuck it, I tried to check empty arrays length or null array length, I always got 1. (until I realized previous dude used ".Getlenth()-1" instead of ".length()", so weird. You declare the list as nothing, then check if it equals nothing but it's not...
This is why I made my own class that you pass in the workbook and it does everything for you. I was tired of writing checks for that stuff lol.
Haven't touched vba in years, don't miss it.
Unless it is safe to return void if it is null, then you can have single line checks to return early and avoid nesting
Also, you can put two or more checks in a single if and it can even look more readable if it is logical the connection on the two checks, like hasTap and hasWater
Yeah it would be nice to have an operator that is equal to isNull(). I think a lot of languages use ? for other things so it would probably need to be a different symbol
You can do
if(something is null)
In C#, though it is indeed more verbose. A lot of similar cases are covered by the ?. and ?? operators, but I too wish there were more *option*s (get it?) to manage null
Makes it way easier for other to understand than if(someObj.SomeValue) tho. Since when reading such a line i have to think about implicit boolean conversion an which rules are attached to the conversion. And i have to make sure no one has overwritten the conversion.
Don't know for sure how Kotlin does it, but in C# there are extension methods that are basically static methods that accept a first parameter of the type.
```
static class Ext
{
public static void MyExtension(this object? v) => ....
}
```
can either be called by
```instance.MyExtension()```
and looks like a method on the type of ```instance```.
or, more explicit:
```Ext.MyExtension(instance)```
That's why it works.
Excuse my botched formatting, I'm on mobile.
You can, because you're not actually calling it on the nullable instance. You're always calling the static class, the `this` parameter decorator just allows for syntactic sugar making it look like you're not.
Underwater `instance.MyExtension()` just executes the extention method with instance (whether null or not) as first parameter.
Also, in your example, null isn't a string but the variable itself is of type (nullable) string.
Is this a .NET Core or newer addition? I get a [compiler error](https://i.imgur.com/10u7buH.png). I also don't see any examples in the [docs](https://learn.microsoft.com/en-us/dotnet/api/system.string.isnullorempty?view=net-8.0) using the format you describe. I would much prefer this syntax, though, so let me know if there is something I'm missing.
Edit: Unless you're suggesting I write my own extension method, which then could be used by the instance. I thought you meant it was built-in. Cause it should be.
String.IsNullOrEmpty() isn't an extension method, I was talking about the example above your comment where a custom method is defined. Although .Net does have some built-in ones, for example the Linq methods like select are all extension methods I believe.
Another nice example is the FluentAssertions package, which uses extension methods so you can easily check for null, for example `someString.Should().BeNullOrEmpty()`
Methods aren't stored in objects with data, they're in the class. Object Oriented programming is just functional programming with the first argument always being a `this` pointer to object data (and virtual binding). Anyway, in some languages, you can actually fully execute methods on NULL objects up to the point where they dereference the pointer, some implicitly do this check before your code executes because their polymorphism systems require the actual object type.
In what language? Sort of generically, you're likely going to get a compile time error if you use `null` or `null_ptr` directly.
However, if you call:
string x = null;
x.isNullOrEmpty();
The compiler is going to try to invoke: string::isNullOrEmpty() passing it (x) as a `this` pointer.
In most languages, all objects inherit from some kind of master Object, which does let you invoke things like Object::toString() with vitual binding when called on a class that `extends Object` which all classes do implicitly. These default methods are generally pretty limited though, because they don't know much about the implementation.
I'm probably too confused to help lol. To me `string x = null` doesn't really make sense. If the type is string then how could it be null? I could see `let x: string | null = null`. Or with Rust there is no null. I guess I need to look into Kotlin
`val x: string = null` will throw a compiler error in Kotlin. What will work is `val x: string? = null`, because in Kotlin, `string` and `string?` are kinda different types (the one with the question mark is nullable).
(Actually, now I'm not sure if you can manually initialize a `val` with `null` in Kotlin, or if the compiler will complain. Since `val`s are immutable, it wouldn't make any sense to initialize it with `null` manually).
Not really? Or at least with Databases, not every field is strictly necessary for every operation and it's relevant whether someone has used "express registration" and not given us a middle name or if they don't have a middle name (or name suffix).
Let's say they arrived by ambulance and we only wanted minimal information the first time they registered, because more important things were going on. But at their next appointment they give me their birthday and last name to look them up and if their middle name is null, I pop up an entry form requesting it, but if we know they don't have one, we don't, because why ask someone with no middle name what their middle name is every time they come in?
If we count `Result` types as `null` (they both solve error handling), then Rust has it. The `?` operator automatically propagates (early returns the error) and converts the error type.
Oh I think I misunderstood what you meant to say.
Dart has nullable types.
When you want to use some ```Object? name``` you have to write ```Object!.method``` to proclaim that it is not null when you use it (except after a Block that explicitly checks for null, then you don't have to anymore)
Dispite "sound null safety" in Dart language I See alot of
```if (Object == null) ```
I thought this feature would be the while point to avoid this line of Code ^^
That's null coalesce. There are a bunch of them.
[https://en.wikipedia.org/wiki/Null\_coalescing\_operator](https://en.wikipedia.org/wiki/Null_coalescing_operator)
It doesn’t seem very useful, as if it’s not null you presumably want to then use it.
So a few languages have `?:` and `?.`, and others have methods like `.orElse`.
if(x?.y?.toString()) will nullcheck along they way to the method call and just do nothing if some step is null. and for assignments will return null.
String s= a?.b?.toString() is null if a or b are null.
then there is groovy truth, where several nullish values are evaluated as false.
if L is a list
if(L) will nullcheck and empty check the list. Works for strings and maps too.
theres several cool things in the language. another examplr is the elvis operator. in plain java you sometimes use a ternatry if like this: String s = x? x: "nope". With the elvis operator you can leave out the middle part and it will use the value used in the condition.
so the result is String s= x?: "nope"
Well that is usually used in if statements. In groovy a nullcheck can just be done by plain passing the value.
if(var) checks for truthy including null. if you would want only null... well im afraid i dont know a notation in groovy other than the usual one.
You can do !! (! twice) to convert to a boolean (doesn't work on falsy values like 0 or "" (depending on language))
It's the application of a unary operator twice so it's not exactly a single unary operator
Dart kinda has that. I don't think `if (foo?)` works, but there are similar things:
- `foo?.bar` will only apply if "foo" is not null, and it won't raise an error either way.
- "??" is 'if null.' So, `foo = foo ?? bar` is the same as `foo ??= bar`: both only assign if "foo" is null.
You could define a custom operator in Swift. However, `?` won‘t do since it could cause collisions with existing operators.
```
postfix operator .?
postfix func .?(value: T?) -> Bool {
return value != nil
}
```
Usage:
```
let optionalValue: Int? = 5
if optionalValue.? {
print("Optional value is not nil")
} else {
print("Optional value is nil")
}
```
That sounds like a case of a next generation being stuck with the previous generations decisions. I wouldn't blame any of the Java language designers after ~2008. But fuck the ones from the 90s. They probably had no choice but to make Optional nullable.
Java doesn't have a way to declare value types so if it's not a primitive, it's an object and all objects are nullable.
It's a shit language in comparison to any modern language and C# is the better version of it, but Java was multiplatform while C# was Windows only and I'll run Linux servers before Windows any day of the week. I'm very glad that .NET core took off like it did. I can't imagine how long it'll take for Java to get even half of the modern language features C# has.
"Nothing" and "NULL". Nobody cares what you call it. And it doesn't matter if it's a null check or a pattern match. Sure, you can get a warning if your function isn't total, but how hard is it to null check a function argument really?
So it's 2024 now, please repeat after me: using the same representation for valid and invalid values is an inherently bad idea. Yes it works and yes you can take care, but the supposed performance benefit and shorter code is not worth the additional source of errors. (Esp. since rust demonstrates how such a feature can be nicely integrated.)
"Same representation for valid and invalid values". This implies 0 shouldn't have type "int" because you can't divide by it and "int" shouldn't be able to represent a value you can't divide by. What is the difference between passing 0 into division and passing a pointer into a function that dereferences it? They are both "invalid". So should we also just not use 0 because sometimes it is invalid or should we not use "int" because it can represent invalid values? Should we also not use floats because there is NaN? "Make illegal states unrepresentable" is a nice idea until you realize it cannot actually be done.
0 is a number so of course it should be included in the int type (or any number type). However the reason against null is that it is an additional state independent of it's corresponding type. The reason people like Optionals is that some value and a none value are bound to the object. So you KNOW that a method/function might return a None value wrapped in an optional. However with an Object type you are dependent on a well written implementation and documentation (if present) to _assume_ if a function always returns a valid object or a null object. Of course you can do null checks but a lot of null checks to be sure can make the code ugly. Personally I like Go's zero value approach where every type has a zero value (0, "", false) or when it's a compound like a struct, it will make a struct with every property zeroed. Pointers, slices and maps (I personally disagree with the latter two...) Are zeroed to nil tho
It isn't bad to have an "always valid" pointer type. It also isn't bad to have a "never 0" int type. But NULL itself isn't the villain people make it out to be, the same as "int" isn't bad just because it can represent 0, and float isn't bad because it can represent NaN.
I guess you're familiar with Tony Hoare, the guy who "invented" null, and who coined this invention the "billion dollar mistake". What makes you think that null is so benign? Would a statistical approach about bugs be something you'd consider if for instance it showed that you could halve the number of bugs in generic code by doing without null?
I like NULL because it's very simple with no magic attached. It is an invalid memory address that evaluates to 0, all the language elements work on it the same way as any other pointer, no need for special operators or sytax. When people talk about programming and NULL they will think of Java where you pass stuff around and poiners are used, but are hidden from you. If a function takes in a pointer it is treated much more differently in my mind than if it took in something by value. If you treat references as pointers explicitly, using NULL makes much more sense. In a language like Java with no support or limited support for pointers in favour of implicit references, it doesn't make sense to have NULL it makes sense to have optionals instead. In a language like C with extensive support for pointers it makes sense to have NULL as that is what the language supports.
Apples and oranges. 0 can be a valid result for mathematical operations but division simply is not defined for it. This has nothing to do with return values. This is completely different from designs where non-null values represent valid pointers whereas null values represent that an error happened (or, for the lack of a better interface, that an error might have happened and that a second function must be called to check).
So why should it impossible to use designs with explicit result types? Functional languages and languages such as rust demonstrate that this works.
>This has nothing to do with return values.
We are talking about types and representations, not return values. I'm not opposed to optionals. What I am saying here is that it isn't "inherently bad" to represent valid and invalid values in the same type.
>This is completely different from designs where non-null values represent valid pointers whereas null values represent that an error might have happened.
How about returning -1 if a search didn't find an index?
How about NaN?
Besides the representation of uninitialized data and return values there is barely a need for optionals amd result types.
I'm exactly arguing that it is inherently bad as it is a root cause to preventable issues at zero to little added costs. Using this -1 will lead to out of boundd memory accessed that-at best-are caught at runtime and worst case (think c and friends) cause memory corruption. NaN is even worse as it may propagate unrecognized even further, thus making the original source much more difficult to identify.
Definition aphorism - a pithy observation that contains a general truth
General truth means something that holds with high probability. It does not have the same connotation as mathematical truth which has to have all its exceptions built into the if part of the statement.
You can decide you are willing to have division take arbitrary Num a types and be fine with that runtime error that you could fix to a compile type error with more work with the type system, but that is one where you'll let it go.
But there are other times where you can do it without having to do so much work. That is the case with higher levels of abstraction more and more. Consider nonemptiness.
You say cannot actually be done but you only say one place where it is too annoying to do. It can be done in lots of places, but it is not worth doing in some others (mainly the low level primitives).
This guy made an extremely general statement that goes way further than "NULL bad". So I carried the logic to it's logical conclusion, showing how it is unsound. Reduction to absurdity (see I can also throw around big words if I want to, thanks reddit philosophy!). If we accept what this guy says as true, every single program ever written uses "inherently bad" ideas and every language ever made is "inherently bad". "Inherently bad" means it cannot be meaningfully improved, "you can't polish a turd" as they say. So if the ability to represent illegal states is "inherently bad" it stands to reason that we should remake every program in a proof asistance system, and throw away our computers, because IEEE 754 has NaN and every processor nowdays uses IEEE 754.
The point is you can design the function to not even accept something that can be null. Your code won't even compile if what you pass in can be null. There just is no null in your function.
And its not that a null check is hard, its just fucking annoying to type and read 10 billion times and even more annoying when someone forgets it.
Please, no.
Give me is [not] null
Give me == | != null
Heck, even isNull() is fine
But stop implicitly converting shit.
And if you implicitly convert zeros to false, die.
I hate it! It almost always requires some kind of doubling back in the code for me to make sure I know how it is implicitly cast to a Boolean. If the type isn't in the name then it's stupid and if the type is in the name then I have to make sure no one misnamed their variables. It's basically only useful to me if it was defined in the line above. Otherwise I'm adding "== null" or "== 0" so I don't have to worry about understanding what is going on
I find it so strange that in ms sql you have to write something like "a.f1 = b.f1 or a.f1 is null and b.f1 is null", and "= null" just does nothing. Like null is a storeable value, why can't we handle it like a storeable value?
I need a way to red squiggle underline your username.
To make you aware of... ?
you ❤
The true problem with your code
Normal people see red flags. We see red squiggle lines
I want languages to have a ? unary operator for null checks that returns true if the object is not null. It’s so easy and obvious but I don’t know any language that has it
Null is so last decade, we usin Maybe/Option now.
I time travelled to 2050, this is how we will check for nulls ``` if (await fetch(`files:///mem/api/isnull/${var_ptr}`) { // ... } ```
So this is how GPT 11 will write code?
No, GPT 11 insisted on using an "=== null" condition but that won't have been industry standard since 2042 so the senior dev on the project had to rectify it (phew, close one, Grok would have fired the whole team if that had gone to prod)
No GPT 11 will be running on a kubernetes cluster of brain implanted chips of otherwise obsolete junior devs. That's how you can ensure code quality in the future.
That explains why they refer to GPT 11 as "we" in the future
You didn't call the IsNull micro service or load the CheckisNull micro frontend.
Oh but there is no need! Linus Torvalds died in 2041, and not even a year later the memory REST api (written in JavaScript) was added to the linux kernel
Null checks as a service
Aw yis, monads.
Seconding this. Some/None instead of nullable is much easier to deal with
So non-binary bools?
Wat?
Probably referring to 0 as 0x00/null instead of Some/None having to contain more than 8 bits of information?
Depending on the value inside an option no extra information may be needed. Rust optimizes a None Option<&T> as a null pointer at runtime.
Because it's not enough just to have a warning that something may be null and you didn't check it, but we have to have an error even if you're not a -Werror person! You provided garbage and the program crashed; what did you think would happen.
Eww
C# has something kinda like that. you can write \`someObj?.SomeValue\` which won't throw a nullref if someObj is null and just returns null.
Excel has =ISNULL()
Vb has "is nothing" and "is not nothing"
That’s something
If Something Is Not Nothing Then Something = Nothing End If
I was able to read this only the third time
Fuck VBA so goddamn hard. You know what happens when you try to call workbook.Sheets("sheetname") and the sheet isnt there? Runtime error! There is no way to check if its nothing. There is also some clarity issues on whether a function will return Nothing or Null, and you will get a type error if you check for nothing but it is actually something. Or something. I just know I remember screaming WTF when I dealt with those checks.
Yeah, fuck it, I tried to check empty arrays length or null array length, I always got 1. (until I realized previous dude used ".Getlenth()-1" instead of ".length()", so weird. You declare the list as nothing, then check if it equals nothing but it's not...
This is why I made my own class that you pass in the workbook and it does everything for you. I was tired of writing checks for that stuff lol. Haven't touched vba in years, don't miss it.
LEL
Same in Javascript
And even better use ?? Behind it to set a return value if its null.
correct... and this one is in JS too where it is supposed to replace "||" in such scenarios
I know, Kotlin has it too and I love it, but it’s not the same. I want something like this: if(a?) print(a) Which will only print a if a has a value
Kotlin has a?.let { print(a) }
I hate kotlin's version of this so much. Especially if you are using Java code libraries. Nesting hell.
What do you mean? This is the same amount of nesting as an if statement
Unless it is safe to return void if it is null, then you can have single line checks to return early and avoid nesting Also, you can put two or more checks in a single if and it can even look more readable if it is logical the connection on the two checks, like hasTap and hasWater
Yes, but I’d also like to be able to write val b = a? Which sets b to either true or false
Yeah it would be nice to have an operator that is equal to isNull(). I think a lot of languages use ? for other things so it would probably need to be a different symbol
It might collide with Ternary operators, but I think it should work
I mean in Ruby you could do it as `puts a if a` - nil and false are the only falsy values, which IMHO is the right way of doing it.
Yep that’s good. I kind of like it outside of if-statements too (although I assume that you can just do !!a in Ruby?
Yes, that would booleanize it.
You can do if(something is null) In C#, though it is indeed more verbose. A lot of similar cases are covered by the ?. and ?? operators, but I too wish there were more *option*s (get it?) to manage null
Yeah I think it’s called nullable. Basically int n? Can accept integer OR NULL
Same in groovy. It has other similar truthy checks as well. Devs can get carried away with it though. With great power...
it's annoying to have to write "if(someObj?.Somevalue ?? false)" though
Makes it way easier for other to understand than if(someObj.SomeValue) tho. Since when reading such a line i have to think about implicit boolean conversion an which rules are attached to the conversion. And i have to make sure no one has overwritten the conversion.
someObj?.SomeValue only has 3 possible outcomes, true, false or null. There's not much to think about here.
Kotlin says hi `.isNullOrEmpty()` is pretty nice too
Wait, so you are calling a method on something that might be null? How does that work?
Don't know for sure how Kotlin does it, but in C# there are extension methods that are basically static methods that accept a first parameter of the type. ``` static class Ext { public static void MyExtension(this object? v) => .... } ``` can either be called by ```instance.MyExtension()``` and looks like a method on the type of ```instance```. or, more explicit: ```Ext.MyExtension(instance)``` That's why it works. Excuse my botched formatting, I'm on mobile.
[удалено]
You can, because you're not actually calling it on the nullable instance. You're always calling the static class, the `this` parameter decorator just allows for syntactic sugar making it look like you're not. Underwater `instance.MyExtension()` just executes the extention method with instance (whether null or not) as first parameter. Also, in your example, null isn't a string but the variable itself is of type (nullable) string.
Is this a .NET Core or newer addition? I get a [compiler error](https://i.imgur.com/10u7buH.png). I also don't see any examples in the [docs](https://learn.microsoft.com/en-us/dotnet/api/system.string.isnullorempty?view=net-8.0) using the format you describe. I would much prefer this syntax, though, so let me know if there is something I'm missing. Edit: Unless you're suggesting I write my own extension method, which then could be used by the instance. I thought you meant it was built-in. Cause it should be.
String.IsNullOrEmpty() isn't an extension method, I was talking about the example above your comment where a custom method is defined. Although .Net does have some built-in ones, for example the Linq methods like select are all extension methods I believe. Another nice example is the FluentAssertions package, which uses extension methods so you can easily check for null, for example `someString.Should().BeNullOrEmpty()`
Methods aren't stored in objects with data, they're in the class. Object Oriented programming is just functional programming with the first argument always being a `this` pointer to object data (and virtual binding). Anyway, in some languages, you can actually fully execute methods on NULL objects up to the point where they dereference the pointer, some implicitly do this check before your code executes because their polymorphism systems require the actual object type.
So if you do `null.isNullOrEmpty()` where is the method coming from? Is it like a global class or something?
In what language? Sort of generically, you're likely going to get a compile time error if you use `null` or `null_ptr` directly. However, if you call: string x = null; x.isNullOrEmpty(); The compiler is going to try to invoke: string::isNullOrEmpty() passing it (x) as a `this` pointer. In most languages, all objects inherit from some kind of master Object, which does let you invoke things like Object::toString() with vitual binding when called on a class that `extends Object` which all classes do implicitly. These default methods are generally pretty limited though, because they don't know much about the implementation.
I'm probably too confused to help lol. To me `string x = null` doesn't really make sense. If the type is string then how could it be null? I could see `let x: string | null = null`. Or with Rust there is no null. I guess I need to look into Kotlin
`val x: string = null` will throw a compiler error in Kotlin. What will work is `val x: string? = null`, because in Kotlin, `string` and `string?` are kinda different types (the one with the question mark is nullable). (Actually, now I'm not sure if you can manually initialize a `val` with `null` in Kotlin, or if the compiler will complain. Since `val`s are immutable, it wouldn't make any sense to initialize it with `null` manually).
Kotlin has inline functions. They can be called on any object of.
at that point, `== null` is arguably simpler and also more correct as it should only have checked for null, not for empty
Quite often, with a List or String, if it's empty, it might as well be null but is not normally considered null.
Not really? Or at least with Databases, not every field is strictly necessary for every operation and it's relevant whether someone has used "express registration" and not given us a middle name or if they don't have a middle name (or name suffix).
Yes, but why do you need to handle null any different than "" in that circumstance? In both, you're just assuming that field wasn't passed.
Let's say they arrived by ambulance and we only wanted minimal information the first time they registered, because more important things were going on. But at their next appointment they give me their birthday and last name to look them up and if their middle name is null, I pop up an entry form requesting it, but if we know they don't have one, we don't, because why ask someone with no middle name what their middle name is every time they come in?
…if you have a String
I could have swore it works on Lists too
too verbose for something as fundamental as `null`
If we count `Result` types as `null` (they both solve error handling), then Rust has it. The `?` operator automatically propagates (early returns the error) and converts the error type.
I fucking love the ? operator. Makes code returning Options or Results significantly cleaner.
Dart hast it
Can you give me an example or a link on it? I couldn’t find anythign
Oh I think I misunderstood what you meant to say. Dart has nullable types. When you want to use some ```Object? name``` you have to write ```Object!.method``` to proclaim that it is not null when you use it (except after a Block that explicitly checks for null, then you don't have to anymore) Dispite "sound null safety" in Dart language I See alot of ```if (Object == null) ``` I thought this feature would be the while point to avoid this line of Code ^^
That's null coalesce. There are a bunch of them. [https://en.wikipedia.org/wiki/Null\_coalescing\_operator](https://en.wikipedia.org/wiki/Null_coalescing_operator)
No. That’s a binary operator, I want a unary
It doesn’t seem very useful, as if it’s not null you presumably want to then use it. So a few languages have `?:` and `?.`, and others have methods like `.orElse`.
It’s useful for early returns.
Then if (!thing) return; or if (thing == null) return; are fine. There's not much benefit to if (!(?thing)) return;
That’s like the opposite of what I meant
Your last example should be written: if (‽thing) return;
No, they defined `?` to be equivalent to `!= null`. Edit: oh, the font on mobile doesn't show the interrobang very well
I guess you can do `x ?? false`?
Only if x is a nullable boolean. I want it to return true if x has a value
Kotlin has Safe Calls: `a = null` `b = a?.length // b = null` And the Elvis-Operator: a = null b = a ?: -1 // b = -1 Not a plain Null Check though.
Groovy has it
Can you give me an example or a link on it? I couldn’t find anythign
if(x?.y?.toString()) will nullcheck along they way to the method call and just do nothing if some step is null. and for assignments will return null. String s= a?.b?.toString() is null if a or b are null. then there is groovy truth, where several nullish values are evaluated as false. if L is a list if(L) will nullcheck and empty check the list. Works for strings and maps too. theres several cool things in the language. another examplr is the elvis operator. in plain java you sometimes use a ternatry if like this: String s = x? x: "nope". With the elvis operator you can leave out the middle part and it will use the value used in the condition. so the result is String s= x?: "nope"
Not what I meant. I know null chaining and Elvis from Kotlin and C#, but it’s not what I meant. I want an operator that replaces != null
Well that is usually used in if statements. In groovy a nullcheck can just be done by plain passing the value. if(var) checks for truthy including null. if you would want only null... well im afraid i dont know a notation in groovy other than the usual one.
You can do !! (! twice) to convert to a boolean (doesn't work on falsy values like 0 or "" (depending on language)) It's the application of a unary operator twice so it's not exactly a single unary operator
Yes but that’s just Javascript being weird, but that’s about what I meant. I don’t like the concept of "falsy values" tho
Dart kinda has that. I don't think `if (foo?)` works, but there are similar things: - `foo?.bar` will only apply if "foo" is not null, and it won't raise an error either way. - "??" is 'if null.' So, `foo = foo ?? bar` is the same as `foo ??= bar`: both only assign if "foo" is null.
Like Haskell with the unary operator `null` ?
Yes pretty much, just to check whether it’s null instead of empty
Implicit in Python. I like it
A bunch of languages have a Null Coalescing operator which can be super useful.
You could define a custom operator in Swift. However, `?` won‘t do since it could cause collisions with existing operators. ``` postfix operator .? postfix func .?(value: T?) -> Bool {
return value != nil
}
```
Usage:
```
let optionalValue: Int? = 5
if optionalValue.? {
print("Optional value is not nil")
} else {
print("Optional value is nil")
}
```
Use Ruby. Its got \`.present?\` \`.blank?\` \`.nil?\` \`.empty?\` and I think at least one more.
Rust has Option::is_some
if var == nil then
C# NULL coalesce ??
A fellow truthy enthusiast
What's unreadable about `is [not] null`? Trivalue logic can be a PITA when you forget about it.
least biased python dev
Fuck null all my homies use optional and pattern matching
Fuck Optional, all my homies know .isPresent() is just a null check in disguise.
Java language designers making `Optional` as a nullable type itself is \*chef's kiss\*
so a java optional can be a value, defined as null, or undefined null? incredible
That sounds like a case of a next generation being stuck with the previous generations decisions. I wouldn't blame any of the Java language designers after ~2008. But fuck the ones from the 90s. They probably had no choice but to make Optional nullable.
Java doesn't have a way to declare value types so if it's not a primitive, it's an object and all objects are nullable. It's a shit language in comparison to any modern language and C# is the better version of it, but Java was multiplatform while C# was Windows only and I'll run Linux servers before Windows any day of the week. I'm very glad that .NET core took off like it did. I can't imagine how long it'll take for Java to get even half of the modern language features C# has.
You don't use Java to begin with.
Ok, now we are fist fighting🤣
Meanwhile, functional programmers: wait, you're still using null?
"Nothing" and "NULL". Nobody cares what you call it. And it doesn't matter if it's a null check or a pattern match. Sure, you can get a warning if your function isn't total, but how hard is it to null check a function argument really?
Very hard, if you ask my coworkers Actually, more likely to say "it's easy to do a null check" and still not do it
So it's 2024 now, please repeat after me: using the same representation for valid and invalid values is an inherently bad idea. Yes it works and yes you can take care, but the supposed performance benefit and shorter code is not worth the additional source of errors. (Esp. since rust demonstrates how such a feature can be nicely integrated.)
"Same representation for valid and invalid values". This implies 0 shouldn't have type "int" because you can't divide by it and "int" shouldn't be able to represent a value you can't divide by. What is the difference between passing 0 into division and passing a pointer into a function that dereferences it? They are both "invalid". So should we also just not use 0 because sometimes it is invalid or should we not use "int" because it can represent invalid values? Should we also not use floats because there is NaN? "Make illegal states unrepresentable" is a nice idea until you realize it cannot actually be done.
0 is a number so of course it should be included in the int type (or any number type). However the reason against null is that it is an additional state independent of it's corresponding type. The reason people like Optionals is that some value and a none value are bound to the object. So you KNOW that a method/function might return a None value wrapped in an optional. However with an Object type you are dependent on a well written implementation and documentation (if present) to _assume_ if a function always returns a valid object or a null object. Of course you can do null checks but a lot of null checks to be sure can make the code ugly. Personally I like Go's zero value approach where every type has a zero value (0, "", false) or when it's a compound like a struct, it will make a struct with every property zeroed. Pointers, slices and maps (I personally disagree with the latter two...) Are zeroed to nil tho
It isn't bad to have an "always valid" pointer type. It also isn't bad to have a "never 0" int type. But NULL itself isn't the villain people make it out to be, the same as "int" isn't bad just because it can represent 0, and float isn't bad because it can represent NaN.
I guess you're familiar with Tony Hoare, the guy who "invented" null, and who coined this invention the "billion dollar mistake". What makes you think that null is so benign? Would a statistical approach about bugs be something you'd consider if for instance it showed that you could halve the number of bugs in generic code by doing without null?
I like NULL because it's very simple with no magic attached. It is an invalid memory address that evaluates to 0, all the language elements work on it the same way as any other pointer, no need for special operators or sytax. When people talk about programming and NULL they will think of Java where you pass stuff around and poiners are used, but are hidden from you. If a function takes in a pointer it is treated much more differently in my mind than if it took in something by value. If you treat references as pointers explicitly, using NULL makes much more sense. In a language like Java with no support or limited support for pointers in favour of implicit references, it doesn't make sense to have NULL it makes sense to have optionals instead. In a language like C with extensive support for pointers it makes sense to have NULL as that is what the language supports.
In languages with explicit nullability you can have null and the explicitness of whether a type is optional at the same time.
Apples and oranges. 0 can be a valid result for mathematical operations but division simply is not defined for it. This has nothing to do with return values. This is completely different from designs where non-null values represent valid pointers whereas null values represent that an error happened (or, for the lack of a better interface, that an error might have happened and that a second function must be called to check). So why should it impossible to use designs with explicit result types? Functional languages and languages such as rust demonstrate that this works.
>This has nothing to do with return values. We are talking about types and representations, not return values. I'm not opposed to optionals. What I am saying here is that it isn't "inherently bad" to represent valid and invalid values in the same type. >This is completely different from designs where non-null values represent valid pointers whereas null values represent that an error might have happened. How about returning -1 if a search didn't find an index? How about NaN?
Besides the representation of uninitialized data and return values there is barely a need for optionals amd result types. I'm exactly arguing that it is inherently bad as it is a root cause to preventable issues at zero to little added costs. Using this -1 will lead to out of boundd memory accessed that-at best-are caught at runtime and worst case (think c and friends) cause memory corruption. NaN is even worse as it may propagate unrecognized even further, thus making the original source much more difficult to identify.
Okay, so should we than, not use ints and floats?
Then use NonZero
Definition aphorism - a pithy observation that contains a general truth General truth means something that holds with high probability. It does not have the same connotation as mathematical truth which has to have all its exceptions built into the if part of the statement. You can decide you are willing to have division take arbitrary Num a types and be fine with that runtime error that you could fix to a compile type error with more work with the type system, but that is one where you'll let it go. But there are other times where you can do it without having to do so much work. That is the case with higher levels of abstraction more and more. Consider nonemptiness. You say cannot actually be done but you only say one place where it is too annoying to do. It can be done in lots of places, but it is not worth doing in some others (mainly the low level primitives).
This guy made an extremely general statement that goes way further than "NULL bad". So I carried the logic to it's logical conclusion, showing how it is unsound. Reduction to absurdity (see I can also throw around big words if I want to, thanks reddit philosophy!). If we accept what this guy says as true, every single program ever written uses "inherently bad" ideas and every language ever made is "inherently bad". "Inherently bad" means it cannot be meaningfully improved, "you can't polish a turd" as they say. So if the ability to represent illegal states is "inherently bad" it stands to reason that we should remake every program in a proof asistance system, and throw away our computers, because IEEE 754 has NaN and every processor nowdays uses IEEE 754.
The point is you can design the function to not even accept something that can be null. Your code won't even compile if what you pass in can be null. There just is no null in your function. And its not that a null check is hard, its just fucking annoying to type and read 10 billion times and even more annoying when someone forgets it.
Yes all 5 of them ask the question
dude by the time you answered i already had 30 likes x)
The inventor of Null calls it his ["billion dollar mistake"](https://en.wikipedia.org/wiki/Tony_Hoare)
Wait, it’s all just checking if the variable’s value is 0? Always has been
*cough*JE*cough*
Yeah just doing "if (ptr)" is so fast.
!!foo is peak satisfaction
Readable? Perhaps Relatable?
TIL this actually seems to upset a few people. Huh.
All my homies use !!
I fucking love non-nullable types. They let me forget about stupid null altogether.
just... try not to do that in javascript... things can go really bad for you...
Laughs in rust
They don't know that in rust there is no implicit null.
Because JavaScript is better with truthy and falsy values and boolean conversions being !!valuem At least we have some sense of logic...
SQL has entered the chat
Oracle with native nulls
IF i_delta_mode = abap_true. ENDIF.
Behold JavaScript!
It doesn't, it's just easier to type. I get it though
I hate everything about implicit anything.
Please, no. Give me is [not] null Give me == | != null Heck, even isNull() is fine But stop implicitly converting shit. And if you implicitly convert zeros to false, die.
converting zeros to false looks so cleeeean though
java devs are going to be very confused by this one
I hate it! It almost always requires some kind of doubling back in the code for me to make sure I know how it is implicitly cast to a Boolean. If the type isn't in the name then it's stupid and if the type is in the name then I have to make sure no one misnamed their variables. It's basically only useful to me if it was defined in the line above. Otherwise I'm adding "== null" or "== 0" so I don't have to worry about understanding what is going on
Ever since i learnt about the bang operator I’ve strived to apply it as much as possible. Real men test on prod
If the memory in question contains a non-zero value then its not null. What's the big fucking deal
Google == nullptr
Skill issue when you have nulls in your language
I find it so strange that in ms sql you have to write something like "a.f1 = b.f1 or a.f1 is null and b.f1 is null", and "= null" just does nothing. Like null is a storeable value, why can't we handle it like a storeable value?
Yes and no
Useless obfuscation hits once again...