C++ (Undefined Behavior)

Undefined behavior, quite possibly a segmentation violation, on attempt to use an out-of-bounds index, such as any index would be in the case of an empty vector.

cl-existence-oriented/lastpos.cxx (Source)

    if ( !items.empty( ) ) {
        std::cerr << "last item: " << items.back( ) << std::endl;
    }

• No compilation checks are made about unguarded access to a vector. Burden is on programmer to remember to test that an index is within bounds before accessing an item from a vector.

• Two separate operations which must be explicitly programmed: emptiness test and access.

• Inconsistent item access interface compared with std::map type. Burden is on programmer to remember differences.

• Returns a value which does not need to be unwrapped before use.

Go (Panic)

Panics on attempt to use an out-of-bounds index, such as any index would be in the case of an empty slice.

cl-existence-oriented/lastpos.go (Source)

        count := len(items)
        if count > 0 {
                lastItem := items[count-1]
                fmt.Fprintf(os.Stderr, "last item: %d\n", lastItem)
        }

• No compilation checks are made about unguarded access to a slice. Burden is on programmer to remember to test that an index is within bounds before accessing an item from a slice.

• Two separate operations which must be explicitly programmed: emptiness test and access.

• Inconsistent interface compared with map type. Burden is on programmer to remember differences.

• Returns a value which does not need to be unwrapped before use.

Python (Raised Exception)

Raises IndexError exception on attempt to use an out-of-bounds index, such as any index would be in the case of an empty sequence.

cl-existence-oriented/lastpos.py (Source)

    if items: print( "last item: {}".format( items[ -1 ] ), file = stderr )

• Burden is on programmer to test that an index is within bounds before accessing an item from a sequence.

• Two separate operations which must be explicitly programmed: emptiness test and access.

• Returns a value which does not need to be unwrapped before use.

• Reasonably consistent item access interface compared with collections.abc.Mapping types.

Rust (Wrapped Value)

Returns an Option, which must be unwrapped before the accessed value, if it exists, can be used.

cl-existence-oriented/lastpos.rs (Source)

    if let Some(last_item) = items.last() {
        writeln!(stderr(), "last item: {}", last_item).ok();
    }

• Burden is on programmer to test whether wrapper contains a value.

• Burden is on programmer to unwrap value.

• Accidental use of raw Option is possible in some cases.

• Single operation: both existence information and value returned together.

• Consistent return value interface compared with rest of standard library.

• Compile-time safety guarantee against panics and undefined behavior.

C++ (Wrapped Entry)

Returns an iterator, which must be unwrapped before the accessed value, if it exists, can be used.

cl-existence-oriented/nomassoc.cxx (Source)

    const auto wrapped_needle = haystack.find( "needle" );
    if ( wrapped_needle != haystack.end( ) ) {
        std::cerr << "needle: " << wrapped_needle->second << std::endl;
    }

• Burden is on programmer to test whether wrapper contains a value.

• Burden is on programmer to unwrap value.

• Accidental use of raw iterator is possible in some cases.

• One of three different ways to access a value from a map.

• Single operation: both existence information and value returned together.

C++ (Zero-Initialized Value)

Creates and returns new entry with zero-initialized value if entry is absent.

cl-existence-oriented/nomassoc.cxx (Source)

    if ( haystack.contains( "needle" ) ) { // Requires C++20 std::map.
        std::map<std::string, int> mutable_haystack( haystack );
        std::cerr << "needle: " << mutable_haystack[ "needle" ] << std::endl;
    }

• If the zero-initialized value can be valid data, then the burden is on programmer to test for presence to disambiguate a valid zero-initialized value from an absent entry.

• Inconsistent item access interface compared with std::vector type. Burden is on programmer to remember differences.

• Cannot work with const maps as it must be able to create missing entry (internal mutation of data structure).

• Two separate operations: existence test and access.

• Key must be referenced twice: once for the existence test and once for the access. This poses a software maintenance issue since a change of key literal or key variable name would need to happen in two different places.

• One of three different ways to access a value from a map.

• Returns a value which does not need to be unwrapped before use.

C++ (Raised Exception)

Raises std::out_of_range exception on attempt to access an absent entry, such as in the empty collection case.

cl-existence-oriented/nomassoc.cxx (Source)

    if ( haystack.contains( "needle" ) ) { // Requires C++20 std::map.
        std::cerr << "needle: " << haystack.at( "needle" ) << std::endl;
    }

• Burden is on programmer to test whether the entry is present prior to access.

• Two separate operations: existence test and access.

• Key must be referenced twice: once for the existence test and once for the access. This poses a software maintenance issue since a change of key literal or key variable name would need to happen in two different places.

• One of three different ways to access a value from a map.

• Returns a value which does not need to be unwrapped before use.

Go (Zero Value)

Returns the zero value for the value type if the entry is absent.

cl-existence-oriented/nomassoc.go (Source)

        needle, ok := haystack["needle"]
        if ok {
                fmt.Fprintf(os.Stderr, "needle: %d\n", needle)
        }

• If the zero value can be valid data, then the burden is on programmer to test the existence boolean to disambiguate a valid zero value from an absent entry.

• Inconsistent item access interface compared with slice type. Burden is on programmer to remember differences.

• Returns a value which does not need to be unwrapped before use.

• Single operation: both existence information and value returned together.

Python (Raised Exception)

Raises KeyError exception on attempt to access an absent entry, such as in the empty collection case.

cl-existence-oriented/nomassoc.py (Source)

    if 'needle' in haystack:
        print( "needle: {}".format( haystack[ 'needle' ], file = stderr ) )

• Burden is on programmer to test whether the entry is present prior to access.

• Two separate operations: existence test and access.

• Key must be referenced twice: once for the existence test and once for the access. This poses a software maintenance issue since a change of key literal or key variable name would need to happen in two different places.

• Returns a value which does not need to be unwrapped before use.

• Consistent interface compared with collections.abc.Sequence types.

Python (Sentinel Value)

Returns None if the entry is absent.

cl-existence-oriented/nomassoc.py (Source)

    needle = haystack.get( 'needle' )
    if needle is not None:
        print( f"needle: {needle}", file = stderr )

• If None can be valid data, then there is an ambiguity problem which cannot be resolved with this approach to access.

• Even if None is an unambiguous sentinel, a test is still needed against it before the entry value can be used. Burden is on programmer to perform this test.

• Returns a value which does not need to be unwrapped before use.

• Single operation: existence information is encoded as the returned value.

Rust (Wrapped Value)

Returns an Option, which must be unwrapped before the accessed value, if it exists, can be used.

cl-existence-oriented/nomassoc.rs (Source)

    if let Some(needle) = haystack.get("needle") {
        writeln!(stderr(), "needle: {}", needle).ok();
    }

• Burden is on programmer to test whether wrapper contains a value.

• Burden is on programmer to unwrap value.

• Accidental use of raw Option possible in some cases.

• Single operation: both existence information and value returned together.

• Consistent return value interface compared with rest of standard library.

• Compile-time safety guarantee against panics or undefined behavior.

C++ (Wrapped Value)

Returns an iterator, which must be unwrapped before the accessed value, if it exists, can be used.

cl-existence-oriented/next-set-item.cxx (Source)

    const auto wrapped_element = elements.cbegin( );
    if ( wrapped_element != elements.cend( ) ) {
        std::cerr << "set element: " << *wrapped_element << std::endl;
    }

• Burden is on programmer to test whether wrapper contains a value.

• Burden is on programmer to unwrap value.

• Accidental use of raw iterator is possible in some cases.

• Single operation: both existence information and value returned together.

Python (Raised Exception)

Raises StopIteration exception on attempt to get next value from an exhausted iterator.

cl-existence-oriented/next-set-item.py (Source)

    if elements:
        element = next( iter( elements ) )
        print( f"set element: {element}", file = stderr )

• Burden is on programmer to test whether the underlying collection is empty prior to iteration over it.

• Two separate operations: existence test and access.

• Returns a value which does not need to be unwrapped before use.

Rust (Wrapped Value)

Returns an Option, which must be unwrapped before the accessed value, if it exists, can be used.

cl-existence-oriented/next-set-item.rs (Source)

    let mut iterator = elements.iter();
    if let Some(element) = iterator.next() {
        writeln!(stderr(), "set element: {}", element).ok();
    }

• Burden is on programmer to test whether wrapper contains a value.

• Burden is on programmer to unwrap value.

• Accidental use of raw Option possible in some cases.

• Single operation: both existence information and value returned together.

• Consistent return value interface compared with rest of standard library.

• Compile-time safety guarantee against panics or undefined behavior.

Kotlin (Nullable Value)

The optional parameters have nullable types and are assigned null by default.

cl-existence-oriented/optional-arguments.kt (Source)

fun format_title(
    base: String, variant: String? = null, version: String? = null
): String {
    val output = mutableListOf(base)
    if (variant != null) {
        variant.length  // Compilation error if not wrapped in null check.
        output.add("[$variant]")
    }
    if (version != null) {
        output.add("($version)")
    }
    return output.joinToString(separator = " ")
}

• Default value of null must be assigned to each parameter to make it optional.

• If null can be valid data, then there is an ambiguity problem which cannot be resolved with this approach to optional arguments.

• Compile-time safety guarantee only covers unguarded member access to a possibly null variable and not use of that variable itself.

• Unused arguments do not need to be specified at invocation site.

• Argument values do not need to be unwrapped prior to use.

• Compile-time safety guarantee againt unguarded member access to possibly null variable.

Python (Sentinel Value)

The default values of the optional parameters are sentinel values.

cl-existence-oriented/optional-arguments.py (Source)

def format_title_sentinels( base, variant = None, version = None ):
    output = [ base ]
    if variant is not None:
        output.append( f"[{variant}]" )
    if version is not None:
        output.append( f"({version})" )
    return ' '.join( output )

• If sentinel value (None in above case) can be valid data, then there is an ambiguity problem which cannot be resolved with this approach to optional arguments.

• Even if the sentinel is unambiguous, a test is still needed against it before the argument can be correctly used. Burden is on programmer to perform this test.

• Unused arguments do not need to be specified at invocation site.

• Argument values do not need to be unwrapped prior to use.

Python (Raised Exception)

No explicit declaration of optional parameters. Arguments are passed via dictionary of extra arguments that do not bind to any declared parameters. Attempt to access an unbound argument in dictionary will result in a KeyError exception.

cl-existence-oriented/optional-arguments.py (Source)

def format_title_args_dict( base, **nomargs ):
    output = [ base ]
    if 'variant' in nomargs:
        output.append( "[{}]".format( nomargs[ 'variant' ] ) )
    if 'version' in nomargs:
        output.append( "({})".format( nomargs[ 'version' ] ) )
    return ' '.join( output )

• Burden is on interface maintainer to ensure that usable parameters are properly documented since they will likley not be inferred by an automatic documentation generator.

• Burden is on interface user to discover usable parameters in code, if they are not properly documented.

• Test for existence in dictionary of optional arguments needed before optional argument can be used. Burden is on interface user to perform this test.

• Key must be referenced twice: once for the existence test and once for the access. This poses a software maintenance issue since a change of key literal or key variable name would need to happen in two different places.

• Unused arguments do not need to be specified at invocation site.

• Argument values do not need to be unwrapped prior to use.

Rust (Wrapped Value)

Each optional parameter declared as with an Option type. Arguments are either None or a value-bearing Some.

cl-existence-oriented/optional-arguments.rs (Source)

fn format_title(base: &str, variant: Option<&str>, version: Option<&str>) -> String {
    let mut output: Vec<String> = vec![base.to_string()];
    if let Some(data) = variant {
        output.push(format!("[{}]", data));
    }
    if let Some(data) = version {
        output.push(format!("({})", data));
    }
    output.join(" ")
}

• Burden is on function developer to inspect Option and unwrap it into separate variable, if it exists, before use in function.

• Accidental use of raw Option possible in some cases.

• Burden is on function invoker to pass an Option variant for each argument with optional existence at each invocation site. A change of function signature could force an update of each invocation site, which is a code maintenance issue.

• Consistent interface compared with other parts of the language.

• Compile-time safety guarantee against panics or undefined behavior.

There is a nice blog post on additional approaches to optional arguments in Rust.