Something like that is possible, but makes the language/compiler more complicated by introducing a whole new concept to the source distribution. It also doesn’t address the cases where you want to do a parse but don’t have the dependent source files, e.g. in a source browser tool like ViewVC.
-Chris > On Oct 1, 2017, at 4:17 PM, Jonathan Hull <jh...@gbis.com> wrote: > > Gotcha. What if the definitions were in a special file similar to the > info.plist that was read before other parsing, with one file per package? > > Thanks, > Jon > > >> On Oct 1, 2017, at 4:09 PM, Chris Lattner <clatt...@nondot.org> wrote: >> >> On Sep 30, 2017, at 7:10 PM, Jonathan Hull <jh...@gbis.com> wrote: >>> I have a technical question on this: >>> >>> Instead of parsing these into identifiers & operators, would it be possible >>> to parse these into 3 categories: Identifiers, Operators, and Ambiguous? >>> >>> The ambiguous category would be disallowed for the moment, as you say. But >>> since they are rarely used, maybe we can allow a declaration (similar to >>> how we define operators) that effectively pulls it into one of the other >>> categories (not in terms of tokenization, but in terms of how it can be >>> used in Swift). >> >> This is commonly requested, but the third category isn’t practical. >> >> Swift statically partitions characters between identifiers and operators to >> make it possible to parse a Swift source file without parsing all of its >> dependencies. If you could have directives that change this, it would be >> difficult or perhaps impossible to parse a file that used these characters >> without parsing/reading the transitive closure of dependent modules. >> >> This is important for compile speed and some tooling, and is an area that C >> gets wrong - its grammar requires all headers to be parsed in order to >> distinguish between type names and normal identifiers. >> >> -Chris >> >> > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
