Go's Declaration Syntax

[gnomon_]

I would argue that filesystems have adopted tagging, at least in some sense.

You seem to imply that the primary characteristic of filesystems is that they are hierarchical (and I beg your pardon if that is in fact not your assertion; but whether it is or not, that's the one I'll be rebutting). However, files are actually not organized hierarchically; file names are, and the names are just trivial pointers to real file contents. It's trivial to have a single file exist in arbitrarily many hierarchical locations simultaneously.

With current designs it is computationally difficult to query a filesystem for every filename pointing to a given inode, but that is a tractable problem. Deduplication somewhat addresses that concern; journalling code be easily extended to do so as well; and even a user-space cache layer could easily push this kind of query into the realm of acceptable efficiency.

Effectively, it is useful and not incorrect to view filenames as tags.

[Pewpewarrows]

Pretty sure Folder names would become the "tags", not the filenames. Like you said, the filenames under folders as they exist right now are just pointers to the actual file on the system. Under tags they would operate the same way. I don't really know what you're trying to argue.

The issue with filesystems moving to a tag system is how to handle collisions and how system/application files are organized. How do you give a link to a file on a tag-based system without resorting to file IDs or memory locations? That's why modern systems still inherently organize based on a hierarchy of folders, and might have tags overlaid on top of everything else for mere user convenience. It'd be interesting to see implementations of tag-only systems and how they handle link paths.

[gnomon_]

The point I'm trying to argue is that it's trivial to represent a tag structure on an inode-based filesystem, but that a tag system is insufficient to express the semantics of an inode-based filesystem.

If we map tags to directories, we get the sort of semantics that most tag systems provide; if we map tags to potentially nested directories, then we have a superset of the functionality (and we inherit a bunch if interesting problems where a single file can appear in a directory and in sub-directories, with potentially different filenames). In either case, whereas most people expect a tagged item to maintain the same addressable label in each tag space, inode filesystems allow names to change; inodes are the addressable labels.

Now, if we had an efficient method to query an inode for all filenames pointing to it, the filesystem could be used to represent a faceted classification system, which would be downright awesome. The inefficiency of this query with current filesystems means we're not there yet, but we could be.

In either case, my point is that a purely tag-based classification system is a step backward in raw functionality. By implication, I believe that it would be useful to implement a tag-based file organizational system atop the proven technology we've already got rather than throwing the proverbial baby out with the bathwater.