I guess that's true, but I very much doubt errors like this would come up very often. Out of precaution, we could make guix lint issue us a warning whenever a non-ASCII character is detected in a package name or elsewhere. This would lower the chances of such oversights occurring even more.
On Thu, Aug 24, 2023 at 7:30 PM Kaelyn <kaelyn.al...@protonmail.com> wrote: > > Hi, > > On Tuesday, August 22nd, 2023 at 6:49 AM, Eidvilas Markevičius > <markeviciuseidvi...@gmail.com> wrote: > > > Therefore, my proposal is to relax these limitations as much as > > possible (or at least somewhat) and to allow some more freedom when it > > comes to naming packages and other kinds of items in the store. We > > could, of course, still disallow all the main problematic characters, > > such as NUL, /, $, ~, space, newline and a few others, but other than > > that, I don't see any reason to forbid any of the remaining ones from > > being used. > > While I don't really have an opinion on the matter aside from the biases > of growing up in the US, one non-trivial issue with Unicode store paths > and package names which hasn't been mentioned is that of Unicode > equivalence[1], particularly homographs[2]. For example U+0061 and U+0430 > (the Latin and Cyrillic small letter "a", respectively) are often visually > identical but programmatically distinct. If not handled well, it could > lead to untypable package or store names by virtue of the user having to > guess which Unicode code point(s) is/are the correct one(s) for a certain > visual glyph. > > Cheers, > Kaelyn > > [1] https://en.wikipedia.org/wiki/Unicode_equivalence > [2] https://en.wikipedia.org/wiki/IDN_homograph_attack
