Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better URL scheme/name demangling #17

Open
mrzv opened this issue Oct 23, 2018 · 4 comments
Open

Better URL scheme/name demangling #17

mrzv opened this issue Oct 23, 2018 · 4 comments

Comments

@mrzv
Copy link

mrzv commented Oct 23, 2018

Is it possible to demangle the names in the filenames? I feel a URL scheme is very important for documentation. A3CT12C20T23E is a lot less readable than A<T1,T2>.

@fosterbrereton
Copy link
Contributor

I agree that what we have right now is not pretty. The problem is that those characters are not unreserved according to the URI specification, so we have to mangle them. If you have an alternate solution that is more legible and equally functional, let me know.

@mrzv
Copy link
Author

mrzv commented Oct 24, 2018

Well, one hack would be to borrow angle brackets from unicode. U+3008 and U+3009,〈〉. From my cursory reading, they are allowed in URIs, but not in C++ identifiers. (This could be wrong, I didn't dig too deep.) There are some obvious downsides, but it's a solution.

@mrzv
Copy link
Author

mrzv commented Oct 24, 2018

In the same spirit, but looking a little bit better are small less and greater unicode signs, U+FE64 and U+FE65, ﹤﹥.

@fosterbrereton
Copy link
Contributor

Originally I was going to restrict the characters to the URI RFC, which requires that any non-unreserved characters be encoded. This would also require Unicode characters to be UTF-8 encoded and then escaped. However I am starting to rethink my decision on this, and am willing to consider using the IRI standard for naming instead. That would give us a lot more flexibility in terms of the characters we can use in the paths, and would let us scale back the kind of mangling we'd need to do. I appreciate your input; let me think about it a bit more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants