というわけで最近の進捗が使える段階まで来たのでリリース
明日と明後日はドキュメントを充実させていきます

datetime-string - crates.io: Rust Package Registry
crates.io/crates/datetime-stri

Released initial version v0.1.0🎉

This is a library providing string types (both borrowed and owned) who can contain valid datetime strings (such as "2020-09-24T04:27:21+09:00").

実はべつに直近で何かに必要というわけではないんだけど、なんとなく実装しはじめてしまったので意地でリリース可能品質まで持っていこうとしている (は?)

Show thread

nostd 対応のライブラリ書いてて、 write!(&mut buf[0..4], "{:04}", less_than_10k) みたいなことをしたかったんだけど……険しいぞ

Show thread

* write!() は core::fmt::Write と std::io::Write どちらにも使える

* &mut [u8] は core::fmt::Write を実装せず std::io::Write を実装している

* std::io::Write は core に存在しない

アッ……

内部表現がプリミティブ (String や i64) 型で、アクセスするときだけ proxy を通すみたいなのも考えたんだけど、所有権まわりがあまり素敵な感じにならないので却下したいところ
(一応 #[repr(transparent)] などで unsafe するとノーコストで型変換はできるんだけど……)

Show thread

serde の serialize / deserialize 実装の提供を必須とすることにすれば中間形式へのフォールバックはできるんだけど、本当にそれでいいのか……?

Show thread

ただそうなると、「特定の型としてメモリ上に存在する限りは必ず validation が済んでいる」という保証が消えることになる。
たとえば NodeId 型に String でアクセスできてしまうと「データを保持する」はできても「性質や制約を保持する」はできなくなってしまう。
そういう点では未知のデータ型には最初からアクセスできない方が安心ではある……

Show thread

たとえば警告を出すにしてもデバッグ表示みたいなのは欲しくなるし、あるいは何らかの中間形式にダンプしたくなるかもしれないし、そういうことを考えると何かしらのフォールバックの形式に落としてアクセスできる方が良い気はしているんだよな

Show thread

たとえば属性の既知の部分だけ処理するとして、実装にとって未知の属性は型を知らないので内容に一切アクセスできない、というのは良い設計だろうか……?

構造体に無限に foo: Option<Foo> が並んで嵩張るのが嫌なので typemap 的なものを用意しようとしたんだけど、 Box<dyn std::any::Any> を使ってしまうと Clone できなくなるな……悩ましい

nostd & alloc crate で使えるライブラリを作ろうとしてたんだけど、 HashMap が使えないの地味に悲しい (どうしよう) (機能的には BTreeMap でも問題ないんだけど、あまり素敵ではない……)

Show thread

Tracking issue for libcore + no_std stabilization · Issue #27701 · rust-lang/rust
github.com/rust-lang/rust/issu

HashMap が alloc になくて std only…… うーん

Show more
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!