Understood. Thanks, Jon
> On Oct 1, 2017, at 4:20 PM, Chris Lattner <clatt...@nondot.org> wrote: > > 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
