Make `Path` a type #499

New issue

Open

opened 2024-09-01 22:45:31 +00:00 by rbt · 2 comments

rbt commented

2024-09-01 22:45:31 +00:00

Owner

Currently, Path and related types are type aliases for strings. This provides no type safety and makes it impossible to e.g. provide different template instantiations for paths and strings, even when semantics differ. Wouldn't it be nice if paths were a thin wrapper around strings with defined semantics? We can make it happen!

Currently, [`Path` and related types are type aliases for strings.](https://git.lix.systems/lix-project/lix/src/commit/02eb07cfd539c34c080cb1baf042e5e780c1fcc2/src/libutil/types.hh#L25-L31) This provides no type safety and makes it impossible to e.g. provide different template instantiations for paths and strings, even when semantics differ. Wouldn't it be nice if paths were a thin wrapper around strings with defined semantics? We can make it happen!

rbt added the

devx

label 2024-09-01 22:45:31 +00:00

rbt referenced this issue

2024-09-01 22:45:53 +00:00

Make more path settings `PathsSetting`s #498

jade commented

2024-09-01 22:47:38 +00:00

Owner

Need to check what CanonPath does and how it should relate to this desired type. Other than that I'm for it.

pennae commented

2024-09-01 23:10:07 +00:00

Owner

CanonPath is much more restricted and can't be used here, but its interface is broadly fine to clone and make Path a concept. we'd suggest not using std::path just yet even if it looks appealing because we will absolutely die when given non-posixly paths (which std::path supports, and we currently treat posixly regardless)

CanonPath is much more restricted and can't be used here, but its interface is broadly fine to clone and make `Path` a concept. we'd suggest not using `std::path` just yet even if it looks appealing because we will absolutely die when given non-posixly paths (which `std::path` supports, and we currently treat posixly regardless)

👍 1