Some pretty… interesting… naming conventions. One of the types is called:
mse::rsv::TXSLTACSSSXSTERandomAccessIterator
What to make of this? The readme provides this guidance:
> The "CSSSXSTE" part of the typenames stands for "Contiguous Sequence, Static Structure, XSLTA, Type-Erased".
But it nowhere defines XSLTA. With some help from ChatGPT, I can guess that "XS" stands for "execution scope" (since the readme talks a lot about execution scopes), and "LTA" probably stands for "lifetime annotated" (since one part says that "rsv::TXSLTAOwnerPointer<> is a 'lifetime annotated' version of TXScopeOwnerPointer<>").
But what about the namespaces, "mse" and "rsv"? I can find nothing to explain what those might stand for.
Anyway.
I really like the idea of this project. There are contexts where I cannot use Rust and would love to have a way equivalent safety guarantees in C++. Even at the cost of rewriting the code. And even at the cost of ugly code, because there will be some necessary ugliness when retrofitting lifetimes into C++'s existing syntax and semantics.
But "TXSLTACSSSXSTERandomAccessIterator" is unnecessary ugliness. There are better ways to get ideas across than acronym soup.
There are some other practical issues with the project, such as inconsistent licensing annotations, and the fact that it seems to depend on specific Clang versions (and thus will probably bitrot if it stops being maintained).
Still, it seems promising and I may use it someday.
You figured out all the letters of the acronym. I'm kinda impressed :) I should probably state it in the documentation, but I made the names kinda comically verbose and ugly to imply that, while these names will always be valid, presumably shorter nicer aliases will be more commonly used. Choosing nice names isn't really part of my skill set. I may be subconsciously hoping the user community will at some point come up with a set of nicer aliases that will just be adopted as de facto standard :)
"rsv" stands for "requires static verification" (to ensure safety). A lot of elements in the library get their safety enforcement via the type system and aren't really dependent on an analyzer like scpptool for their safety. The ones that are generally go in the "rsv" namespace.
I can't remember what "mse" stands for right now. I'm pretty sure the "s" stands for "safe" or "safety". At one point, and possibly still, the idea was to support entities maintaining their own version of the library if they wanted (to completely eliminate dependency risk). In that case one might want to change all the "mse" namespace references to their own namespace name. scpptool is coded to allow you to specify the base namespace of your version of the library.
> There are some other practical issues with the project, such as inconsistent licensing annotations
Any licensing issue is just me being careless/lazy I assume. I don't intend for there to be any restrictions. I think I just tried to make everything original to the project use the boost license, which seems totally permissive to me. If I need to do something to fix the licenses, let me know.
> the fact that it seems to depend on specific Clang versions (and thus will probably bitrot if it stops being maintained)
The only reason there is any dependency on clang version is because the clang libraries keep making breaking changes on successive versions. It used to be really bad, but these days they're generally minor breakages. At this point if someone doesn't want to wait to update the version of clang that scpptool uses, it's pretty much just a matter of doing a search-and-replace for the version number in the build script and makefile, and then fixing whatever annoying thing the new version broke. A lot of times it's them slightly reorganizing the (large) set of clang libraries scpptool needs to build against (which requires modifying the makefile). One of the goals of this project is to be as small of a dependency risk as possible. I think it compares favorably to some of the alternative solutions in that regard.
> The "CSSSXSTE" part of the typenames stands for "Contiguous Sequence, Static Structure, XSLTA, Type-Erased".
But it nowhere defines XSLTA. With some help from ChatGPT, I can guess that "XS" stands for "execution scope" (since the readme talks a lot about execution scopes), and "LTA" probably stands for "lifetime annotated" (since one part says that "rsv::TXSLTAOwnerPointer<> is a 'lifetime annotated' version of TXScopeOwnerPointer<>").
But what about the namespaces, "mse" and "rsv"? I can find nothing to explain what those might stand for.
Anyway.
I really like the idea of this project. There are contexts where I cannot use Rust and would love to have a way equivalent safety guarantees in C++. Even at the cost of rewriting the code. And even at the cost of ugly code, because there will be some necessary ugliness when retrofitting lifetimes into C++'s existing syntax and semantics.
But "TXSLTACSSSXSTERandomAccessIterator" is unnecessary ugliness. There are better ways to get ideas across than acronym soup.
There are some other practical issues with the project, such as inconsistent licensing annotations, and the fact that it seems to depend on specific Clang versions (and thus will probably bitrot if it stops being maintained).
Still, it seems promising and I may use it someday.