Antonis Geralis planetis-m

Cheap exceptions

Goals:

Avoid Rust's Option/Either manual error handling strategy.
Make exceptions cheaper.
Avoid error translation between Nim libraries by construction. The new vocabulary type ErrorCode is what should be used. Wrappers should translate errors to ErrorCode.
Make the error out of memory easier to handle.
Resolve once and for all the "error codes vs exceptions" choice.

Open Source Business Challenges and Reality

Original Japanese note here.

Original Author: Rui Ueyama (creator of the mold linker)

Translated by @windowsboy111

Minimally edited by @lleyton

Suggestions for Nim v2

Note: this document is a collection of all proposals from the Nim v2 ideas thread. As such, it is/was not by any means reflective of intentions for 2.0: though I've updated this with accepted and implemented proposals.

Breaking changes

Features

kobi, exelotl, didlybom, solomonthewise, pdkoekfr, snej, apropos: Adopt Options module and make types not nil by default (discussion)
Zoom, apropos: Overhaul stdlib to work with view types and/or options/results for error handling

Intro

The below is a breakdown / bird's eye view of how a sparse-array backed ECS like EnTT or Shipyard works.

Please see the thanks and references at the bottom - without their help I would not have been able to share this breakdown with you... everything here is really just notes and rephrasing of what they've written already :)

Also, these notes do not cover archetype systems (like unity) nor adaptations of archetypes (like in Flecs). Though there's a couple comparative footnotes at the end.

Here we go!

Binding to C Libraries with Nim

	Understand the Task: Grasp the main objective, goals, requirements, constraints, and expected output.
	- Minimal Changes: If an existing prompt is provided, improve it only if it's simple. For complex prompts, enhance clarity and add missing elements without altering the original structure.
	- Reasoning Before Conclusions: Encourage reasoning steps before any conclusions are reached. ATTENTION! If the user provides examples where the reasoning happens afterward, REVERSE the order! NEVER START EXAMPLES WITH CONCLUSIONS!
	- Reasoning Order: Call out reasoning portions of the prompt and conclusion parts (specific fields by name). For each, determine the ORDER in which this is done, and whether it needs to be reversed.
	- Conclusion, classifications, or results should ALWAYS appear last.
	- Examples: Include high-quality examples if helpful, using placeholders [in brackets] for complex elements.
	- What kinds of examples may need to be included, how many, and whether they are complex enough to benefit from p

	import nico
	import nico/vec

	type GridLayout* = enum
	gridSquare
	gridHexPointyTop

	type Grid*[T] = ref object
	layout*: GridLayout
	wrapX*: bool

	import nico
	import nico/vec
	import strformat

	type Object = ref object
	color: int
	pos: Vec2f
	rawPoints: seq[Vec2f]
	angle: float32
	highlightEdgeIndex: int

	type
	Handness = enum
	hLeft,
	hRight

	NearFar = enum
	nfDefault,
	nfReverse

	Vec3 = object

	double t = 0.0;
	const double dt = 0.01;

	double currentTime = hires_time_in_seconds();
	double accumulator = 0.0;

	State previous;
	State current;

	while ( !quit )