So what I want is not necessarily the mere existence of a distinct string path type, which i could create myself very easily, but rather for that type to be used consistently throughout the standard library wherever paths are used, such that the standard way to deal with paths is through the singular `type Path = distinct string` or any of its potential subtypes that inherits from `Path` . If additional types of paths are necessary (e.g. relative path, absolute path, symlink, filepath, folderpath), then they can inherit from `Path`. Additionally, what I'm proposing does not just apply to string types, but also to other types such as URL's, IP addresses, etc. that would similarly benefit from being modeled as distinct string types because they also are conceptually different from free form text and obey domain specific rules.
What I'm proposing is a redesign of the standard library to be more organized in how it deals with the semantics of different types that are now represented as strings, but are conceptually distinct from free form text because they conform to domain specific rules. I think this change will have beneficial ripple effects throughout the Nim package ecosystem and enhance the developer experience. I think Nim will feel like a tidier language where doing the right thing becomes trivially obvious because the language design nudges you in the right direction. Also better tooling can be developed if this change is adopted, further improving the developer experience. If you don't see why this is necessary, just think of how clunky working with `decimal` or even `int` type would be if we modeled it as a plain `string` type. Yes you could have all the same procs available (though the names may have to change to avoid collision with names of procs that work on free form string but non decimal string), but now you have to pay the cognitive overhead of differentiating between free form text and decimal/int whenever you interact with either type, and your type system won't catch obvious bugs because as far as the type system is concerned both are just `string` types. Having one library available that does the right thing and conceptually distinguishes `decimal` from string doesn't solve the problem if your standard library conflates `string` with `decimal` types everywhere else and consequently the wider library ecosystem will also conflate the types because they want to interact with the procs defined in the standard library.
