Go and Simplicity Debt Redux

Re:Go and Simplicity Debt Redux by YZF on Sunday June 18, 2017 @04:50PM (#14582850)

maybe<Foo> or it's C++ equivalent optional<Foo> is more expensive. You now either have a bool + a value, or a pointer that can be nullptr. So you're consuming more memory at the very least and if you want to panic on accessing a value that doesn't exist that means an extra comparison as well. Granted there are situations the compiler can optimize this away in C++. I also find that starting to use optional in C++ code leads to it being used everywhere and for everything which introduces new run-time failure modes that can't be detected on compile time and in general IMO messes up the code.

An alternative is to split find and access into two separate operations like C++ or to provide "in" like Python. Is there any language where a map/set access returns an optional/maybe?

FWIW I agree the current solution is clunky. It's clunkiness was evident prior to the template/generics question :)

[ Parent | on HN ]

Re:Go and Simplicity Debt Redux by comex on Sunday June 18, 2017 @06:23PM (#14583315)

I was envisioning that the maybe-returning version would be a separate method, equivalent to the current two-return-value variant, which of course already has that overhead.

Having the default return a 'maybe' would be a possibility; I'm pretty sure the practical performance difference would be completely negligible, given all the other stuff a map lookup has to do, but it might have worse ergonomics. In that case you'd probably want a builtin optional-unwrapping operator like some languages have, so it's not too verbose if you expect the element to be there.

> Is there any language where a map/set access returns an optional/maybe?

Swift is one. It has ! as an unwrap operator, along with other syntax sugar for optionals, so it's not verbose:

      5> let q = ["a": "b"]
    [snip]
      6> q["a"]
    $R2: String? = "b"
      7> q["x"]
    $R3: String? = nil
      8> q["a"]!
    $R4: String = "b"
      9> q["x"]!
    fatal error: unexpectedly found nil while unwrapping an Optional value

[ Parent | on HN ]

Re:Go and Simplicity Debt Redux by codebje on Monday June 19, 2017 @12:08AM (#14584581)

A maybe<T> in a language with halfway decent support for sum types is most likely a tagged pointer to a T, if it is reified at all.

A clever compiler is likely to do the same thing for a pair of (bool, T): represent the bool as a tag in the pointer, store the T. If the value is reified at all.

What new run-time failure modes do you get with optional? Is it just what happens when you blithely ignore the "nothing" possibility and attempt to extract the contained value "on faith" ?

[ Parent | on HN ]