haitaka-types

Crates.iohaitaka-types
lib.rshaitaka-types
version
sourcesrc
created_at2025-04-10 01:59:47.856359+00
updated_at2025-05-07 18:23:32.669261+00
descriptionInternal data types library for haitaka
homepagehttps://github.com/tofutofu/haitaka
repositoryhttps://github.com/tofutofu/haitaka
max_upload_size
id1627513
Cargo.toml error:TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include`
size0
(tofutofu)

documentation

README

haitaka-types ハイタカ型

Internal package for haitaka

This package defines the core data types used in haitaka. It's not intended as stand-alone library (though nothing will prevent you from using it like that).

Splitting off the data types into a separate crate allows haitaka to run a build script to generate slider move hash tables used in move generation based on magic bitboard. Without a separate crate to run against the build script would have to duplicate quite a bit of code or the library would need a separate initialization function -- either as a hidden, lazy initialization or as an explicit initialization step. Both those alternatives are less than ideal.

Setting up a separate crate also ensures a clearer separation of concerns making the codebase easier to maintain, test, and extend.

Commit count: 0

cargo fmt