const head = (input: A[]) => input[0]
head([]) // -> undefined
type NonEmptyArray<T> = { head: T, rest: T[] };
function makeNonEmptyArray<T>(array: T[]): NonEmptyArray<T> | null {
if (array.length == 0) return null;
return { head: array[0], rest: array.slice(1, array.length) };
}
function head<T>(array: T[]): T | null;
function head<T>(array: NonEmptyArray<T>): T;
function head(array: any): any {
if (Array.isArray(array)) {
if (array.length === 0) return null;
return array[0];
}
if (typeof array === "object") {
return array.head;
}
}
It's impossible for Haskell to guarantee an array will not be empty at runtime as well; that's why we can write a new type + a smart constructor to track runtime properties.
type NonEmpty<T> = [T, ...T[]];
function head<T>(input: NonEmpty<T>): T {
return input[0];
}
Maybe you could use "Rest elements in tuple types" and do an overloaded signature like this:
function head<T>(...args: [T, ...any[]]): T;
function head<T>(...args: []): undefined
function head<T>(...args: [T, ...any[]] | []): T | undefined
{
return args[0];
}
You'd have to spread the arguments or use call/bind/apply, though.
config.load_from_file(....
It's an anti-pattern to throw errors for expected behavior.
[0] https://docs.quantifiedcode.com/python-anti-patterns/readabi...
On the other hand, non-atomically asking for permission first in any concurrent (or re-entrant!) context is not just an antipattern but simply wrong and always a possible race condition. It is impossible to write a routine that tries to open a file and is statically guaranteed to succeed.
For me, the funny thing about this article is that I kind of had the core insight just yesterday while hacking together a cli framework, but like the author, I couldn't quite explain what I learned.