Type names should allow using :: as an identifier

[TheRawMeatball]

When describing rust data, it can be prefferable to use the full type names of values to avoid ambiguity. However, this loses a significant amount of ron s simplicity since it forces all type names to be in strings. This is a tiny subset of the features which would be enabled by #242.

[kvark]

How is RON deserializer expected to know the fully qualified path to a type?

[TheRawMeatball]

I don't expect it to. I don't want it to know any types or anything. I just want files where :: tokens are used as part of the type ident to successfully parse.

[kvark]

I guess we can just support parsing "::" there. It's not obvious to me if this would bring any downsides.

[TheRawMeatball]

Hmm, what would I need to do if I wanted to add this myself?

[kvark]

You can start by inspecting see how the parser skips the names in the code, currently.

[Waridley]

Some issues/questions that arise from thinking about this:

• If this is supported, it would be nice (possibly even expected) to be able to directly use any string returned by std::any::type_name ... which may include generic arguments... which may include whitespace, commas, and even the -> symbol and parentheses for Fn* types (though I'm not quite sure how likely it is for any type containing those to be serialized, but it does seem possible if it's something like a PhantomData field...). Suddenly it seems like we should write an entire parser for TypePaths. Or should we just strip any generic parameters when serializing? Or expect users to strip them themselves?
• Should users expect to be able to use <Type as Trait>::AssociatedType as a struct name?
• Should paths be allowed for all identifiers, or should struct names just be special? It seems odd to want to, e.g. use a path for a field name in a struct, when you could just name the struct and deduce the field's path relative to the struct's.
• If treating struct names specially, should there be any verification of the type being deserialized? Given the nearly infinite number of possibilities once you consider re-exports, relative paths, and especially type aliases, this seems extremely difficult and should probably never be an error unless the user explicitly asks for it to be.
• TupleStructs become a bit more tricky to identify since a colon following an identifier could either be either separating a field name from its value, or separating segments of a TypePath. Thus the next byte would have to be checked to see if it's a colon, and then if so, the next byte would have to be a valid first character of an identifier, or < if generics are supported...
• Is the performance impact of all of these additional checks worth it? It's probably not a big deal, but the current implementation is fairly well-optimized.

[TheRawMeatball]

Hmm, I looked into this a bit and before I do any work I realized these idents don't actually get recorded in Value types, which I found very weird. Is there a particular reason they're ignored?

[torkleyy]

@TheRawMeatball

Hmm, I looked into this a bit and before I do any work I realized these idents don't actually get recorded in Value types, which I found very weird. Is there a particular reason they're ignored?

Yes, that's because serde's type model doesn't have any way to pass the ident of a string. It's inspired by JSON which doesn't have them, so we can't get the data from the deserializer to the Value...

[TheRawMeatball]

That's unfortunate :(

[torkleyy]

Yep. However, I'm working on something right now that will allow preserving all the metadata.