Feature request: allow easier board setup beside from_fen() about chess HOT 8 CLOSED

This structure was renamed to BoardBuilder and follows the builder pattern. Otherwise, all the functionality is the same. Board and Game now implement FromStr to convert FEN strings directly into them without the need for an intermediate object.

This was released in 3.1.0.

from chess.

from chess.

I completely agree with your points! (And of course we need the color of a piece, that was a silly mistake by me.) So we could make it the following function:

pub fn setup(
    pieces: impl IntoIterator<Item=(Square, Color, Piece)>,
    side_to_move: Color,
    white_castle: CastleRights,
    black_castle: CastleRights,
    en_passant: Option<File>)
    -> Option<Board> {}

Another thing I noticed that doesn't arise with FENs is that it could happen if the iterator produces the same square more than once. But then we can just return None.

from chess.

Yeah. I thought about that. I even thought you could do a Map<Square, (Color, Piece)>, but it may make the API more difficult to use overall. There's not trait implementation for Map<...> which would mean we'd have to pick a data structure for input. That said, I think either approach is fine.

from chess.

I prefer the iterator solution because then one can simply pass a slice, vector or even a (hash) map. However for the map iterator would have item type (Square, (Color, Piece)), so we probably should use that instead.

from chess.

I didn't see any activity on these and I really liked the idea, so I added an Fen structure myself. It seems to handle the use cases described pretty well. I also added Square::{A1-H8} implementations. It will be released with 3.0.3, hopefully tomorrow depending on the amount of free time I have.

There is now an:

• impl TryFrom<Fen> for Board
• impl From<Board> for Fen
• impl FromStr for Fen
  ... for conversion, and an Error type using failure which enumerates errors.

None of this is on https://crates.io/crates/chess/, yet. I need to document and test Fen better. I also need to decide if I'm really going to deprecate Board::from_fen(). I kind of think so, mostly because it returns an Option<Board> instead of a Result<Board, Error>, which kind of hurts idiomatic use cases.
I also noticed Game::new_from_fen(), but didn't touch it outside of making it use the new structure. It should really return Result<Game, Error> as well, but I obviously didn't want to break the API.

from chess.

Thanks for implementing this! I intended to do it but then things came up... I haven't had a chance to test it yet but I really like the new API. :)

I'm just wondering why you want to deprecate Board::from_fen() but not Game::new_from_fen() since they seem quite similar to me. I don't care much about it, I was just wondering.
Also, deprecations should happen in a minor release (not just patch release), if you want to adhere to semantic versioning (https://semver.org/#how-should-i-handle-deprecating-functionality). (You are, of course, free not to follow it.)

from chess.

Both are good points. I haven't really decided on either. If I deprecate one, I should deprecate both, and impl TryFrom<Fen> for Game as well.

I didn't know the semver rules on this, and I should follow semver, so maybe I'll bump the version to 3.1.0.

from chess.