fixing the 5th bug this week that stems from liberal use of First() on enumerables that are unlikely but not in any way guaranteed to be non-empty.

This shows how useful it is when languages are forcing you to handle the null case if it can be null.

@Lensflare maybe it's useful for idiots who cant check their input

@antigermanist it isn't input, it's from a database previously populated by earlier versions of the same software, with all sorts of constraints ranging from high level business rules (eg. "a product is usually built from at least one part") to low level implementation guarantees (eg. "BOM nodes store the ID of their parent", "exactly one parent ID in a given BOM is null", "The child-parent graph is loop-free")

Both are subject to change.

So, did you check upfront or handled the raised exception? Last one is very pythonic.

@lorentz I know buddy I was just bullying lensflare.

In reality of course it's useful. I converted all the project into strongly types as soon as I could.

@retoor I checked upfront of course, the exception is a null reference in this case, but even if it was a custom empty collection error, it would be difficult to assert that I'm not associating my handler with other error conditions from other collection operations for which it's incorrect.

I think the only case when handling an exception is preferable to preventing it is if the enclosing scope and the exception type fully specify the handler's duties. If the handler would need to assume anything about the line that raised the exception, checking first is better.

Obviously not considering APIs that abuse exceptions to represent non-exceptional, fairly likely outcomes, such as a missing file or network failure.

@lorentz in python it's common to write:

Try:
return val['key']
Except KeyError:
# other stuff

Assuming return.get('key', defval) is not an option some how.

Causing exceptions and handling it is perfectly normal.

@retoor for a single operation it doesn't really cause problems I guess because the source of the error is unambiguous, but I don't see the benefit either. It just looks to me like a clumsy substitute for optional/maybe.

@retoor I guess since Python fully supports neither lambdas nor pattern matching, you actually can't make an implementation of optional as ergonomic as it is in other languages, so this may be the closest Python can get to that.

@lorentz what's wrong with the python lambdas?

@antigermanist bullying me by pretending you are an idiot? Weird, but ok.

@retoor they can't contain statements, just one expression.

@lorentz in Python you can just create a function inside a function. Then return the function. Or pass it wherever. I never use their "lambdas".

What does it mean Python doesn't have pattern matching? Confused.

@Demolishun Pattern matching like in Haskell, Rust, C#, Java, etc. Most modern languages more-or-less agree on the meaning of the word, afaik python doesn't have it at all.

Passing a function by name is far less ergonomic for the purpose of Option. Why would I want to name a block that isn't any more special than the body of an if statement?

why the fuck is vec.remove(index) not an option

what the fuck

AI suggested it to me the other day and I thought it was vec[index] but it is not

also why don't we have entries on vecs so I don't have to peek the first then decide to take it or not. now I'm doing 2 unwraps

@jestdotty vec.remove(index) is absolutely a thing.

https://doc.rust-lang.org/std/vec/...

Keep in mind that since you can't have a hole in a vector, this will shift the end of the vector down an index. If you want holes in your vector, consider a Vec<Option<T>> and vec[index].take()

@jestdotty You can't peek at the first index and then choose whether to take it because you can't mutate the vector while holding a ref to an element. If vector specifically supported this use case, it would be implemented the same way you would implement it externally, except the function that does it would need a closure argument and like 4 generic parameters (two distinct lifetimes, I think one might be implicit). If it's any consolation, the second unwrap will definitely be optimized out

@lorentz I know it's a thing I'm saying it's strange it returns the element and not an option with the element since you could give it an index that doesn't exist

@lorentz yeah I'm aware what the compiler says

but it's a use-case and it's inefficient to implement it with these rules at play and the functions at hand

@jestdotty I see what you mean with remove,. I guess it would be reasonable for it to return a Result. Either way, none of these safe micro-functions are terribly important, since they're trivial to implement for yourself.

@jestdotty Vec has pop_if which removes the last element if a predicate succeeds, and VecDeque has pop_front_if and pop_back_if, so I guess the rationale was that removing the first element is a relatively uncommon operation anyway because of how expensive it is.

Visions of linq dancing through my head lol