JDevlieghere wrote: > Should we have a top level "lldb_plugin" namespace instead of > "lldb_private::plugin"? It would be easier to be able to export only a single > plug-in interface if needed if we did this
What makes it easier to export `lldb_plugin` than `lldb_private::plugin`? I'm only familiar with using an export list in which case it's just another prefix. I also think conceptually this is somewhat confusing or even misleading. We currently have an `lldb` and `lldb_private` namespace which mean very different things. That expectations, combined with the fact that LLDB has plugins, makes it really sound like `lldb_plugin` is the interface we expose for writing (dynamically loadable) plugins. But that's not the case at all, it's actually the opposite: because all the plugins use `lldb_private` in their interfaces, so you need to export `lldb_private` types. Making it a namespace contained in `lldb_private` makes that really obvious. If we ever want to have somewhat stable language plugins for Swift or Rust, we actually will need something like what I describe above: a "somewhat stable" interface that downstream languages can use to implement their language support without having to maintain a full fork (like Swift). We're still pretty far from that, but I wouldn't want to reserve a namespace now that will only make that harder down the line. FWIW I don't feel super strongly about this. I want to understand the benefit of Greg's suggestion because I see a smallish downside to doing it that way and all things being equal we can avoid some confusing in the future. https://github.com/llvm/llvm-project/pull/68150 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
