Rust makes a similar decision, despite having Option and Result.

If you want the Option behavior, there's .get()

Anyways, very cool looking language.

But from what I've seen, most idiomatic Rust code doesn't use the `map[key]` syntax, but instead uses `map.get(key)`.

We must look at very different code :)

I actually didn't realize it was doable (not a heavy rust user - just an enthusiast). Kinda hidden away in docs under an example [0] and isn't in the book under hash maps [1]. Might be worth calling out somewhere explicitly? People getting started with rust probably aren't familiar with the trait-based operator overloading system yet.

[0] https://doc.rust-lang.org/std/collections/struct.HashMap.htm... [1] https://doc.rust-lang.org/book/second-edition/ch08-03-hash-m...

Yeah, might be worth it on the API docs, for sure. Maybe file a bug? :)

> For me using an exception to indicate the lack of a value corresponding to a key in a map (is it really exceptional for this to happen?)

Sometimes it is, sometimes it isn't. Most languages allow you to choose whether you want a hash to throw a key error on non-existing keys or return a signal value. My favorite is the uber-flexible approach and nice syntax in Crystal:

  hash[foo] is sugar for hash.fetch(foo)

  hash[foo]? is sugar for hash.fetch(foo, nil)

  hash.fetch(foo) will return the default value of the hash table on nonexistent keys if one was assigned, otherwise raise keyerror

  hash.fetch(foo, nil) will return nil on nonexistent keys

Seems particularly weird given that it has "Algebraic data types (with Option and Result predefined)."

Well, for good or for bad, python does the same.

You can use dict's get() method to get back a None for missing keys instead of throwing a KeyError exception. That avoids the overhead of checking `if key in dict` or catching KeyError.

Another option, it's very easy to wrap a dict in a defaultdict:

    class optionaldict(defaultdict):
	"""
	A defaultdict that disregards KeyErrors and returns None for missing keys.
	"""
	def __init__(self, *original, **kwargs):
	    super().__init__(lambda: None, *original, **kwargs)

This is almost always a bad idea, though; it doesn't distinguish between

    {k: None}[k]

and

    {}[k]

It's not a generic option, you are polluting memory with non-existing keys.

To be fair, there's utility to avoid it: check first or do a .get(). That helps you be expressive about what you think should/should not exist

I can definitely see the use in that. In some situations a given key not being present would actually be exceptional.