Is it time to stop using sentinel values for null / “NA” values?

Re:Is it time to stop using sentinel values for null / “NA” ... by morelisp on Monday June 05, 2023 @12:55PM (#36199230)

C++ would be the obvious poster child.

It might be more instructive to list some exceptions:

- As described elsewhere in this thread, Julia is able to optimize Array<Option<X>> internally into a bitfield and a tightly-packed array of X

- Rust can use knowledge of a type's valid values to optimize Option<T> into something the same size of T for common T (pointers, arrays, etc, also notably I think user-defined enums which aren't exhaustive of their value space) - but as far as I know it cannot do what Julia does, you need to reach for e.g. https://docs.rs/vec-option/latest/vec_option/

- This is somewhat the raison d'etre for Jai, if it ever gets released.

[ Parent | on HN ]

Re:Is it time to stop using sentinel values for null / “NA” ... by zabzonk on Monday June 05, 2023 @01:05PM (#36199398)

> C++ would be the obvious poster child

to make it obvious, post some code.

[ Parent | on HN ]

Re:Is it time to stop using sentinel values for null / “NA” ... by morelisp on Monday June 05, 2023 @01:11PM (#36199500)

https://www.boost.org/doc/libs/1_34_1/boost/optional/optiona...

    bool m_initialized ;
    storage_type m_storage ;

[ Parent | on HN ]

Re:Is it time to stop using sentinel values for null / “NA” ... by gpderetta on Monday June 05, 2023 @01:35PM (#36199867)

Boost and std optional do not do it, but you can write your optional type that take advantage of the properties of T for optimal storage via traits.

FWIW, we have had this discussion a few months ago on HN.

[ Parent | on HN ]

Re:Is it time to stop using sentinel values for null / “NA” ... by zabzonk on Monday June 05, 2023 @01:16PM (#36199564)

ok, now explain how this " conflate memory layout and type definitions"

[ Parent | on HN ]

Re:Is it time to stop using sentinel values for null / “NA” ... by Dylan16807 on Monday June 05, 2023 @04:15PM (#36202909)

It sticks a bool onto each value, directly attached in memory layout, taking up a byte plus padding bytes, multiplied by how many values you have.

(The compiler is allowed to improve this, but it won't.)

[ Parent | on HN ]

Re:Is it time to stop using sentinel values for null / “NA” ... by morelisp on Tuesday June 06, 2023 @07:01AM (#36210871)

The compiler is only vaguely allowed to do this by general "as if" rules; in practice there are so many formal constraints on field layout I don't think it could do better even with the world's most brilliant optimizer. It would need to behave "as if" if the two fields are laid out next to each other, in address-ascending order, with nothing but padding in between.

[ Parent | on HN ]

Re:Is it time to stop using sentinel values for null / “NA” ... by marcosdumay on Monday June 05, 2023 @02:08PM (#36200448)

C and C++ do really not do that, and programing as if the memory structure is equivalent to the type structure is an undefined behavior factory that will turn your program into a mine field.

But those languages are very good at pretending they mix the two concepts.

[ Parent | on HN ]

Re:Is it time to stop using sentinel values for null / “NA” ... by morelisp on Monday June 05, 2023 @02:20PM (#36200652)

I said conflated, not made formally identical.

[ Parent | on HN ]