Python exposes docstrings because they're not really comments -- they're first-class syntax in the language (overloaded syntax, but still part of the language definition). Go also includes them as part of the language, assuming I understand your description of its setup. Same for Rust, or at least same in that there's only one meaningful implementation of Rust, so it just *is*. C# and Java defined it as part of the language (or standard library, same thing there).
Clang with C++ is the only exception to the rule that this stuff is defined by the language, of the examples you discuss. (Although note that C++11 these days -- in spec, if not in too many implementations -- has attributes and goes into considerable, intricate detail about what an attribute "appertains to".) You're talking implementation-proprietary feature development, pretty much, there. I don't have much confidence in our ability to do that as (see below) a language extension, to be honest. > I guess what I'm trying to say is that SpiderMonkey/JavaScript appears > lacking in the "language services" arena. That's entirely fair. And I think it is a language-level thing, that should be defined in the language proper. Just as it is in Python, Go, Rust, C#, Java, and in C++'s attribute syntax. (And maybe elsewhere, in C++1y? Wish we'd had this discussion a few months ago before that discussion about what we'd bring to the C++ table for desires in future C++ specs, to get the desires out there for discussion.) To the best of my knowledge, no one has proposed anything related to comments or documentation in ECMAScript as language functionality on es-discuss. (That knowledge being occasional mailing-list skimming, mostly of subject lines, occasionally of message bodies, plus a quick subject search for "comment" and for "document" just now.) If this is that important, we should propose something, then champion it through. But to be honest, this isn't something I think SpiderMonkey people should be doing. We understand language semantics. But this is far more an ease-of-use-ish sort of thing, that's better understood, described, specified, brainstormed for information/solutions/details, etc. by active JS authors. I'm not sure anyone on the SpiderMonkey team fits that bill these days. We can kibitz pretty well on this, but the starting point has to be people who write JS regularly, and have dealt with JS documentation setups before and are aware of the full range of what's out there, what's needed, etc. Perhaps devtools people who work with/in JS regularly could help out here, for synergistic goodness or something? Jeff _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
