4 ms·

> My argument is that `std::optional` should not have an operator* at all. `kj::Maybe` does not have operator* nor `operator->`. That’s fair. >> If you want t

> My argument is that `std::optional` should not have an operator* at all. `kj::Maybe` does not have operator* nor `operator->`. That’s fair. >> If you want to dereference an optional that may be null, use the .value_or() method. For the times when you absolutely know the optional has a value use operator > This is putting a lot of cognitive load on the developer. They must remember which of their variables are optionals, Not really. Teams with programmers that are bad at keeping track of the state of their variables can simply have a policy to always use .value_or()/.value() C++ doesn’t impose this on its users because it generally assumes its users are responsible enough to make their own policy. > The fact that they use the same syntax to dereference makes it very easy to get wrong. I disagree, the operator* has the same semantics as pointers did, making it no more semantically hazardous. There exists other methods on optional that have the behavior you want.

kentonv 6y ago
> always use .value_or()/.value() But neither of these solve the problem either. Neither one forces the programmer to really confront the possibility of nullness and write the appropriate if/else block. Throwing an exception rather than crashing is only a slight improvement IMO. > I disagree, the operator* has the same semantics as pointers did, making it no more semantically hazardous. It was already severely hazardous with pointers, that's the problem.
- CyberRabbi 6y ago
  >> always use .value_or()/.value() > But neither of these solve the problem either. Neither one forces the programmer to really confront the possibility of nullness and write the appropriate if/else block. .value_or() actually does and you can certainly add a lint check against dereferencing optional or using .value() if you’d like. C++ does not Yet provide Case-style syntax for handling variants like rust, outside of macros and the standard library will certainly not define macros. I think what you have done for your codebase makes sense based on your preferences but I think the standard optional works pretty well given the variety of code based and styles it’s intended to support. > It was already severely hazardous with pointers, that's the problem. So then don’t use the dereference operator.
  - kentonv 6y ago
    kj::Maybe has an `orDefault()` method that is like `.value_or()` but I find that it is almost never useful. You almost always want to execute different logic in the null case, rather than treat it as some default value.
    - CyberRabbi 6y ago
      Then you can make a quick helper subroutine that adds a monadic interface to optional and you can lint away all non-conforming uses of optional.
- pierrebai 6y ago
  Both problem could have been solve looooooong ago by introducing a type modifier akin to const that carries if a value is verified (or safe or non-null or other. Pick your synonym). int * p; // maybe null! int * verified p; // guaranteed non-null! A looooong time ago (circa... 1994-1995) I designed a hierarchy of smart pointers and had a variety for non-null so that you could declare a function like: void foo(non_null_ptr<T>& p); And know that you don't have to verify for null. All enforced at compile-time. (via the a function on ptr<T> returning a non_null_ptr<T>). With language support around if() and others, C++ could have mde it even more convenient. Even C could have introduced such a tyupe modifier. Whenever I read about pointers being unsafe and how optionals and maybes are the solution, I roll my eyes, because non-null-ptr do the exact same thing. The funny thing is C++ has a non-null ptr (with no language support guarantee though): references. Unfortunately, the language made them not resettable, which makes them unusable in many scenario when you'd want them to change value over time, like in most classes members.
  - CyberRabbi 6y ago
    Isn’t “non null optional” the same as just passing the base type?
    - pierrebai 6y ago
      By reference? Yes. But the idea of a verified type can be extended by using the verified modifier on your own type. For example, you could have a verified matrix type, where the matrix is guaranteed to be valid, non-degenerate. You can apply it to: - matrix - vector - input data of any sort And if teh compiler allowed the programmer to declare their own type modifier, the world is your oyster: you could for example tag that a matrix is a world matrix while another a local matrix and provide a function that converts from one to the other... I wrote a small blog post about the idea: https://www.spiria.com/en/blog/desktop-software/hypothetical-c-extensible-tagging/ https://www.spiria.com/en/blog/desktop-software/hypothetical...
  - ubadair 6y ago
    Are you aware of std::reference_wrapper? https://en.cppreference.com/w/cpp/utility/functional/reference_wrapper https://en.cppreference.com/w/cpp/utility/functional/referen...

kentonv 6y ago

> always use .value_or()/.value() But neither of these solve the problem either. Neither one forces the programmer to really confront the possibility of nullness and write the appropriate if/else block. Throwing an exception rather than crashing is only a slight improvement IMO. > I disagree, the operator* has the same semantics as pointers did, making it no more semantically hazardous. It was already severely hazardous with pointers, that's the problem.

CyberRabbi 6y ago
>> always use .value_or()/.value() > But neither of these solve the problem either. Neither one forces the programmer to really confront the possibility of nullness and write the appropriate if/else block. .value_or() actually does and you can certainly add a lint check against dereferencing optional or using .value() if you’d like. C++ does not Yet provide Case-style syntax for handling variants like rust, outside of macros and the standard library will certainly not define macros. I think what you have done for your codebase makes sense based on your preferences but I think the standard optional works pretty well given the variety of code based and styles it’s intended to support. > It was already severely hazardous with pointers, that's the problem. So then don’t use the dereference operator.
- kentonv 6y ago
  kj::Maybe has an `orDefault()` method that is like `.value_or()` but I find that it is almost never useful. You almost always want to execute different logic in the null case, rather than treat it as some default value.
  - CyberRabbi 6y ago
    Then you can make a quick helper subroutine that adds a monadic interface to optional and you can lint away all non-conforming uses of optional.
pierrebai 6y ago
Both problem could have been solve looooooong ago by introducing a type modifier akin to const that carries if a value is verified (or safe or non-null or other. Pick your synonym). int * p; // maybe null! int * verified p; // guaranteed non-null! A looooong time ago (circa... 1994-1995) I designed a hierarchy of smart pointers and had a variety for non-null so that you could declare a function like: void foo(non_null_ptr<T>& p); And know that you don't have to verify for null. All enforced at compile-time. (via the a function on ptr<T> returning a non_null_ptr<T>). With language support around if() and others, C++ could have mde it even more convenient. Even C could have introduced such a tyupe modifier. Whenever I read about pointers being unsafe and how optionals and maybes are the solution, I roll my eyes, because non-null-ptr do the exact same thing. The funny thing is C++ has a non-null ptr (with no language support guarantee though): references. Unfortunately, the language made them not resettable, which makes them unusable in many scenario when you'd want them to change value over time, like in most classes members.
- CyberRabbi 6y ago
  Isn’t “non null optional” the same as just passing the base type?
  - pierrebai 6y ago
    By reference? Yes. But the idea of a verified type can be extended by using the verified modifier on your own type. For example, you could have a verified matrix type, where the matrix is guaranteed to be valid, non-degenerate. You can apply it to: - matrix - vector - input data of any sort And if teh compiler allowed the programmer to declare their own type modifier, the world is your oyster: you could for example tag that a matrix is a world matrix while another a local matrix and provide a function that converts from one to the other... I wrote a small blog post about the idea: https://www.spiria.com/en/blog/desktop-software/hypothetical-c-extensible-tagging/ https://www.spiria.com/en/blog/desktop-software/hypothetical...
- ubadair 6y ago
  Are you aware of std::reference_wrapper? https://en.cppreference.com/w/cpp/utility/functional/reference_wrapper https://en.cppreference.com/w/cpp/utility/functional/referen...