6 ms·

Can’t you still return null from a function? So even if your return type was optional, you’d have to check if it was null in some cases before unwrapping it. (

Can’t you still return null from a function? So even if your return type was optional, you’d have to check if it was null in some cases before unwrapping it. (Edit: Limited c++ experience, thanks for explaining)

awestroke 8y ago
Sounds like a useless feature in that case
- snowAbstraction 8y ago
  In case, what do you say about returning a class instance from a function in Java? Joking aside, the feature gives you both a value type and documents the intent of function intentionally possibly not returning a value.
  - dasloop 8y ago
    This will be C++ std::expected: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r3.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p032... Returns a value (as in std::optional) than can be null. If so you will get an error explaining what happened.
- archgoon 8y ago
  Java has Optional<T> which is actually nullable, unlike the C++ std::optional (which is a value type, not a pointer). So even if it were nullable, it seems that people find value in expressing "This may not return a valid object, you need to check" as an actual object type is useful. https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional...
  - pjmlp 8y ago
    They plan to sort out that problem when value types are finally part of the JVM.
  - jcrites 8y ago
    I wish and hope that, in some future version of the Java language, they will change the behavior of Java references so that they are explicitly non-null by default, and require an annotation or signifier of some kind to mark them as nullable. The Kotlin language (JVM-based) got this right: https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html In the meantime, Java coding best practices dictate treating all references as non-null in first-party code (defensively checking references received from third-party code, such as with Objects.requireNonNull), and avoiding nullable references in favor of Optional.
    - staticassertion 8y ago
      This won't happen. But Java is likely to get value types, which would be non-null just as in other languages with value types. The issue of Optional<T> being nullable is an extremely uncommon one - I have seen it happen once ever, and there were way bigger issues going on that happened to manifest that way. It's one of those "that's dumb but ultimately makes no difference" problems that many languages have.
jcelerier 8y ago
uh ? unlike languages such as java, or c#, objects aren't nullable in C++, only pointers to objects. You can't do for instance struct foo { // whatever }; foo my_function() { return nullptr; } and thus, std::optional<int> my_function() { return nullptr; } does not compile (rightly).
- iBelieve 8y ago
  Wouldn't it be more correct to say that Java and C# don't have nullable objects either, it's just that they're always used via pointers, so any object reference can be nullable, unlike C++, which allows objects to be passed by value and thus not be nullable?
- pjmlp 8y ago
  C# is not like Java. struct Vector { int x, y; } public class Program { public static void Main() { Vector v = null; } } Also does not compile: "Cannot convert null to 'Vector' because it is a non-nullable value type"
  - jcelerier 8y ago
    well, change that struct into class and it does AFAIK :p Basically, just given `public foo myFunction() { ... }` there's no easy way to know
    - winstonewert 8y ago
      Nope. class and struct are almost the same thing in C++ .
      - jcelerier 8y ago
        yes, I was talking about C#.
        8y ago
HippoBaro 8y ago
std::optional is designed for value semantic. It wouldn't make sense to use it to return a pointer-type.
- Koshkin 8y ago
  But in C and C++ a pointer is a value.
beached_whale 8y ago
No, this isn't java/c#. In C++ only a pointer can be set to nullptr or NULL. std::optional is a value that can store a type T(T is a place holder for a type name). If T is a pointer (such as T * or int *...) then yes you could return null. But that is rare and looks weird. So the value of an optional is either a valid value or it has no value. The default constructed std::optional<T> has no value
- pjmlp 8y ago
  C# has value types, you can't set structs to null.
  - beached_whale 8y ago
    True. Most things are reference types though
    - pjmlp 8y ago
      No in the case of Nullable, which behaves just like std::optional.
      - beached_whale 8y ago
        I see what you are saying, yes. Also, in c++ if you try to use an empty value in an optional<T> it isn't using undefined behavior as dereferencing a null pointer would, plus with optional you get value semantics so things like copy are deep vs copying the pointer. Not sure about C# nullables, but I guess if you copy the .value member it is deep.
slavik81 8y ago
No. In Java every object variable is a reference type. They're all implicitly pointers. Hence why all objects can be null. Java just hides all the dereferencing away. "Object myobject;" creates a pointer/reference rather than an actual object. In C++ you can have pointers to objects, but they're explicitly denoted by an asterisk. The C++ equivalent would be "Object* myobject;" However, you can also directly have object variables in C++. That's not something that exists in Java. A variable declared like, "Object myobject;" can never be null. The myobject variable is a value, just like i in "int i = 5;" is a value.
- repsilat 8y ago
  To expand on this: In C++ a useful heuristic could be to think of values like Java primitives. A C++ integer takes up some amount of space. Maybe it's four bytes on your platform. Integers on your platform take up four bytes. Not "four bytes plus a pointer", but four bytes and that's it. In those four bytes you can store 2^32 values. There's nowhere else to store whether the integer is null -- if you wanted to signal to someone that the value was "missing", you would either have to, - Come up with your own "in-band" signal, like "-(2^31) means 'missing'", or - Have an out-of-band signal, like a separate boolean variable, or keep a pointer to "integer or null". (Pointers being nullable is arguably kinda weird still.) Functions that return an integer in C++ on your platform will put four bytes "in the right place" on the stack. (Or in a register? I don't really know what calling conventions look like...) Again, there's nowhere to signal that the value is missing -- if you don't fill in that memory location or that register, well, there will just be some other (undefined) value sitting in its place that the caller will read. Ditto functions that expect integer arguments etc. Now, this has some interesting consequences: for stack-allocated values in C++, "object identity" tends to be preserved less often than in Java. When you put an object into a `vector`, you'll probably put a copy there. When you mutate that copy or call some function on it, you're not mutating the original. You can get back to "Java semantics" of object identity and nullability etc by using pointers and explicit heap storage.
  - cesarb 8y ago
    > Functions that return an integer in C++ on your platform will put four bytes "in the right place" on the stack. (Or in a register? I don't really know what calling conventions look like...) On a register. I don't know of any mainstream platforms which return simple values like an integer through the stack. For larger values (larger than a word or a couple of words), on the other hand, usually the calling function passes the called function a pointer to a location on the stack where it should write the result. Either way, like you said "there's nowhere to signal that the value is missing".
Buge 8y ago
No you can't. "null" isn't a specific thing in c++. There's nullptr, NULL, and 0. NULL is just a fancy name for 0. If for example you have a function with a return type of string, it must return a string. It cannot return nullptr, NULL, or 0. It could return an empty string. But in some cases you might want to distinguish between empty string and no result, in that case you would want to the return type to be std::optional<std::string> .

awestroke 8y ago

Sounds like a useless feature in that case

snowAbstraction 8y ago
In case, what do you say about returning a class instance from a function in Java? Joking aside, the feature gives you both a value type and documents the intent of function intentionally possibly not returning a value.
- dasloop 8y ago
  This will be C++ std::expected: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0323r3.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p032... Returns a value (as in std::optional) than can be null. If so you will get an error explaining what happened.
archgoon 8y ago
Java has Optional<T> which is actually nullable, unlike the C++ std::optional (which is a value type, not a pointer). So even if it were nullable, it seems that people find value in expressing "This may not return a valid object, you need to check" as an actual object type is useful. https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html https://docs.oracle.com/javase/8/docs/api/java/util/Optional...
- pjmlp 8y ago
  They plan to sort out that problem when value types are finally part of the JVM.
- jcrites 8y ago
  I wish and hope that, in some future version of the Java language, they will change the behavior of Java references so that they are explicitly non-null by default, and require an annotation or signifier of some kind to mark them as nullable. The Kotlin language (JVM-based) got this right: https://kotlinlang.org/docs/reference/null-safety.html https://kotlinlang.org/docs/reference/null-safety.html In the meantime, Java coding best practices dictate treating all references as non-null in first-party code (defensively checking references received from third-party code, such as with Objects.requireNonNull), and avoiding nullable references in favor of Optional.
  - staticassertion 8y ago
    This won't happen. But Java is likely to get value types, which would be non-null just as in other languages with value types. The issue of Optional<T> being nullable is an extremely uncommon one - I have seen it happen once ever, and there were way bigger issues going on that happened to manifest that way. It's one of those "that's dumb but ultimately makes no difference" problems that many languages have.

jcelerier 8y ago

uh ? unlike languages such as java, or c#, objects aren't nullable in C++, only pointers to objects. You can't do for instance struct foo { // whatever }; foo my_function() { return nullptr; } and thus, std::optional<int> my_function() { return nullptr; } does not compile (rightly).

iBelieve 8y ago
Wouldn't it be more correct to say that Java and C# don't have nullable objects either, it's just that they're always used via pointers, so any object reference can be nullable, unlike C++, which allows objects to be passed by value and thus not be nullable?
pjmlp 8y ago
C# is not like Java. struct Vector { int x, y; } public class Program { public static void Main() { Vector v = null; } } Also does not compile: "Cannot convert null to 'Vector' because it is a non-nullable value type"
- jcelerier 8y ago
  well, change that struct into class and it does AFAIK :p Basically, just given `public foo myFunction() { ... }` there's no easy way to know
  - winstonewert 8y ago
    Nope. class and struct are almost the same thing in C++ .
    - jcelerier 8y ago
      yes, I was talking about C#.
      - 8y ago

HippoBaro 8y ago

std::optional is designed for value semantic. It wouldn't make sense to use it to return a pointer-type.

Koshkin 8y ago
But in C and C++ a pointer is a value.

beached_whale 8y ago

No, this isn't java/c#. In C++ only a pointer can be set to nullptr or NULL. std::optional is a value that can store a type T(T is a place holder for a type name). If T is a pointer (such as T * or int *...) then yes you could return null. But that is rare and looks weird. So the value of an optional is either a valid value or it has no value. The default constructed std::optional<T> has no value

pjmlp 8y ago
C# has value types, you can't set structs to null.
- beached_whale 8y ago
  True. Most things are reference types though
  - pjmlp 8y ago
    No in the case of Nullable, which behaves just like std::optional.
    - beached_whale 8y ago
      I see what you are saying, yes. Also, in c++ if you try to use an empty value in an optional<T> it isn't using undefined behavior as dereferencing a null pointer would, plus with optional you get value semantics so things like copy are deep vs copying the pointer. Not sure about C# nullables, but I guess if you copy the .value member it is deep.

slavik81 8y ago

No. In Java every object variable is a reference type. They're all implicitly pointers. Hence why all objects can be null. Java just hides all the dereferencing away. "Object myobject;" creates a pointer/reference rather than an actual object. In C++ you can have pointers to objects, but they're explicitly denoted by an asterisk. The C++ equivalent would be "Object* myobject;" However, you can also directly have object variables in C++. That's not something that exists in Java. A variable declared like, "Object myobject;" can never be null. The myobject variable is a value, just like i in "int i = 5;" is a value.

repsilat 8y ago
To expand on this: In C++ a useful heuristic could be to think of values like Java primitives. A C++ integer takes up some amount of space. Maybe it's four bytes on your platform. Integers on your platform take up four bytes. Not "four bytes plus a pointer", but four bytes and that's it. In those four bytes you can store 2^32 values. There's nowhere else to store whether the integer is null -- if you wanted to signal to someone that the value was "missing", you would either have to, - Come up with your own "in-band" signal, like "-(2^31) means 'missing'", or - Have an out-of-band signal, like a separate boolean variable, or keep a pointer to "integer or null". (Pointers being nullable is arguably kinda weird still.) Functions that return an integer in C++ on your platform will put four bytes "in the right place" on the stack. (Or in a register? I don't really know what calling conventions look like...) Again, there's nowhere to signal that the value is missing -- if you don't fill in that memory location or that register, well, there will just be some other (undefined) value sitting in its place that the caller will read. Ditto functions that expect integer arguments etc. Now, this has some interesting consequences: for stack-allocated values in C++, "object identity" tends to be preserved less often than in Java. When you put an object into a `vector`, you'll probably put a copy there. When you mutate that copy or call some function on it, you're not mutating the original. You can get back to "Java semantics" of object identity and nullability etc by using pointers and explicit heap storage.
- cesarb 8y ago
  > Functions that return an integer in C++ on your platform will put four bytes "in the right place" on the stack. (Or in a register? I don't really know what calling conventions look like...) On a register. I don't know of any mainstream platforms which return simple values like an integer through the stack. For larger values (larger than a word or a couple of words), on the other hand, usually the calling function passes the called function a pointer to a location on the stack where it should write the result. Either way, like you said "there's nowhere to signal that the value is missing".

Buge 8y ago

No you can't. "null" isn't a specific thing in c++. There's nullptr, NULL, and 0. NULL is just a fancy name for 0. If for example you have a function with a return type of string, it must return a string. It cannot return nullptr, NULL, or 0. It could return an empty string. But in some cases you might want to distinguish between empty string and no result, in that case you would want to the return type to be std::optional<std::string> .