What about additional payload in the error? It seems that this option does not allow you to add it.
That's some library specific getMoreErrorInfo API which can then decide of whether to use threadlocal storage for it or if some object can keep this information.
In the same vein, would the standard library be built on top of it? i.e Optionals wherever relevant?
They simply are not relevant when you have exceptions.
Are the sum types 2025 RFC launching with nimony or later?
We add them first to Nim and then later to Nimony.
That's some library specific getMoreErrorInfo API which can then decide of whether to use threadlocal > storage for it or if some object that you have lying around somewhere (typically called a X-"Context") > can keep this information.
Although I understand that this approach would greatly simplify the compiler itself and reduce the overhead of errors/try-catch, I don't think it's a good solution to the problem. It forces developers to make their own decisions (which can greatly affect their impression of the language/libraries), since there is no standard other than return/raise ErrorCode. In addition, the existing ErrorCode may not be sufficient to give a complete picture. For example, Zig also uses error codes, but it also allows you to set your own.
Is full support for Nim 2 Exception \ CatchableError (via --compat) planned? If so, I don't quite understand this decision.
They simply are not relevant when you have exceptions. (Or more generally speaking, when you have some version of raise.)
Aren't you confusing them with Result[T] (that stdlib doesn't have)?
Options are to provide a way to safely and ergonomically signify an absence of value, instead of error-prone and inconsistent reusing of "invalid" values for this. The fact that stdlib doesn't use Options is understandable, since they came later and the language wasn't and still isn't 100% ready not having pattern matching. But it's a bummer, really.
Do you suggest that you're planning to reuse one of the global error codes for this (None)? Isn't this a slight mixing of concerns between lang subsystems?
Congrats for your progress, is always hard to keep focus, and easy to lose momentum.
So here is my attempt to make you lose focus:
typedthreads.nim
snippet:
when TArg isnot void: t.data = param
t.dataFn = tp
when hasSharedHeap: t.core.stackSize = ThreadStackSize
# REQUIRES A FULL MEMORY FENCE INSTRUCTION HERE
var dummyThreadId: int32 = 0'i32
t.sys = createThread(nil, ThreadStackSize, threadProcWrapper[TArg],
addr(t), 0'i32, dummyThreadId)no complex evalution engine for arbitrary compile-time computations
From a language user perspective, this looks quite pretty concerning - compile-time evaluation is useful for all sorts of things, from parsing strformat at compile time to get rid of potential runtime errors to precomputing lookup tables etc and having access to the full language, including composing such constants from other constants that themselves were created with compile-time computaiton is a major feature in Nim.
Having this facility as some kind of second-class citizen is not a viable option, ie the aim with most code that gets executed in such conditions is to reuse the same code for runtime and compile-time and choose which one is used when, depending on context.
A sha256 function is the same, no matter when it's evaluated and doesn't lend itself to the kind of examples that are used to showcase plugin capabilities.
Unless this whole plugin thing is just an implementation stage/detail, and compile-time execution and macros return as first-class citizens, relegating this to {.plugin.} means one of two things:
Hopefully, there's a third way here that I'm missing, or that's missing from the manual?
Not nil tracking
Example looks broken - next is not nil and is in the next paragraph assigned nil.
Hopefully, there's a third way here that I'm missing, or that's missing from the manual?
Sure, see https://github.com/nim-lang/nimony/issues/1443
The manual describes the status-quo, not where we want to be. Heap-based exceptions need to be provided for backwards interop too, for example. Then there is implicit generics missing, yada yada.
Heap-based exceptions need to be provided for backwards interop too, for example.
The "big" change that heap-based exceptions need to be reasonably efficient is to capture the stack trace by address and resolve later - resolving addresses to their debug (string) location adds to their extreme inefficiency, ie it's a cost that is unnecessary at the raise point - the sad part with this particular inefficiency is that in the rare case that the exception-based code is correct and actually catches the exception instead of crashing, the stack trace is not needed.
Since they are short-lived, it could also make sense to give them a specific memory area dedicated to this, further reducing their interactions with the memory manager.
Nim 2.0 doesn't attach stack traces to exceptions in release mode anyway. The fact that our stack tracing sucks is mostly orthogonal and either way, that's an API of its own, see https://github.com/nim-lang/nimony/issues/1442
I spent yesterday trying to get https://github.com/status-im/nim-libbacktrace to work... ;-)