There exists a bijection between the natural and rational numbers that works (approximately) like this:
You create a 1-indexed 2-dimensional grid.
In every field of this grid with position (x, y), put the number x / y.
You start at (1,1) and iterate over the field in the following way:
However...
@DLosc Clearly, the number of Sʨɠɠans is equal to the digit that appears the most, of a minimum of 3 times, in the year, defaulting to 0, if no such digit exists
Every 1011 years, a new Sʨɠɠan comes into existence, before they are all wiped out the next year
I'm considering trying out my inferred-borrowing idea and making a language that transpiles to Rust as an intermediate language
It'd be slightly higher level, with things like Arcs and Mutexes abstrated away, arrays and Vecs would be merged into a single type, that sort of thing
Maybe I'll make it lean slightly more functional than Rust, since it's already got the potential for that, just with its built-in verbosity getting in the way a lot
Not talking about Result vs. exceptions here, like the actual way errors are represented
In OOP/semi-OOP langs they tend to just be classes which inherit from some sort of base Error type
I don't like that
And some langs let you use any type as an error, which is also bad
Problem with the OOP method is that it makes creating new error types annoying
E.g., in Rust you need to make a whole struct, and add the Display trait to get it to print a useful message
So I think an error should be more like a two-element tuple. The first should be like the error's type name; e.g., in a library called http, you might have http::gzip::InvalidGzip as the first item. The second would be a string description. That's it.
The first item would be for matching, so you can handle certain errors, and not others
The second would be how the error is shown to the user if it ends up turning into a panic/fatal
Like in Rust, since you have the freedom to use any type as a Result's Err field, some things return Strings, but most use types with the Error trait
So if you want to actually handle an error, you need to understand what type it is, and hope that it actually lets you handle things how you wanted to, and if it's an Error and you just want to pass it along, you need a Box<dyn ...> which is annoying
@RadvylfPrograms I also think anything that could return an error should be able to specify either a list of possible error types, or a wildcard, with neither requiring creating a new type or using dynamic dispatch
So like, you could have a function which returns either a successful result, a https::tls::TlsHandshakeFailure, a http::gzip::InvalidGzip, or a net::NetworkUnreachable, and if you use this function in your function, and just pass on any errors that the function you used could return, it'll automatically add those three to the list of possible errors your function could return
So for any function which possibly returns an error, you can see exactly which errors are possible, in a standardized way, and handle them conveniently
IMO you should not be doing that with an error in the first place
Your function should be returning an enum or some sort of data structure which can represent invalid indices if you expect those to be a possibility
Errors should be used for things that have either unexpectedly not worked, indicating a bug, or which have gone wrong because of some external factor, like with networking or file operations
So the only processing you should be doing on errors is deciding whether to ignore them, panic, or pass them on to the calling function
Alternatively if you really wanted to use an error for that situation, but also give additional information, you could return a struct containing the error and information about it
suppose a piece of code catches an error that it would like to pass on, but is lower-level than what the user would expect (e.x. an IndexError). the code wants to rethrow it but as a NoMoreItemsError. what if it needs info from the lower level error?
(ofc in this case it doesnt, but i am certain there are cases when it does)
Hmm, that's a good point. Maybe there'd be a way to include a lower level error in an error, so the user would see a NoMoreItemsError with a brief higher level description of what went wrong, and under that would be the IndexError, with any details which would be needed for debugging
I think the issue would mostly be prevented by not using a single error which can encompass multiple types of failures which, to the end user, might be handled differently.
Also, typically errors wouldn't be shown to the user with the expectation that the user reads them, unless they're the writer/debugger of the program, right?
If it's an expected error, like a 400 when requesting something from a dodgy API, it should be handled and the user informed through something other than throwing an error (probably just printing a status message, or displaying a popup in a GUI app). If it's an unexpected error, it's fine if it's low-level and verbose, since the user of a program typically isn't expected to learn why the software they're using isn't working, just pass on the error message to whoever maintains it
There exists a bijection between the natural and rational numbers that works (approximately) like this:
You create a 1-indexed 2-dimensional grid.
In every field of this grid with position (x, y), put the number x / y.
You start at (1,1) and iterate over the field in the following way:
However...
