"I couldn't resolve these symbols" and `deprecated` path

[kylegoetz]

Is your feature request related to a problem? Please describe.

I have a type called Domain. When I use it, I get warned by UCM that it cannot resolve the symbol (I have base installed in lib, and base has a test.deprecated.Domain in it). So whenever I use my type, I have to specify models.Domain to avoid this.

Describe the solution you'd like

I think a child of a namespace called deprecated shouldn't be included when UCM is trying to resolve a name unless it is the only available term/type with that name.

If this is too broad, maybe just do this for anything in lib.base since this will be installed as a dep in nearly every project.

[aryairani]

There's been talk of removing test.deprecated soon, but your suggestion is still good.

Maybe we'd do something like "anything that starts with _ is deprioritized"?

[kylegoetz]

I like that. I'm working on a library now with a ton of "internal" code, and I'm still playing around with conventions for marking things internal.

One option has been to "reverse-namespace" them with internal:

myFoo.internal : Nat -> ...
myFoo.internal = todo "now any time someone wants to call this, they cannot avoid seeing 
"internal" in the name

another has been to prefix with internal to group it all together, so at least in UI they're all filed away inside a namespace people will be nudged not to browse into

another has been what you're talking about, prefixing with _ (I think in Python they do __this__ and in TypeScript it's common to __this and _this).

The craziest idea I've had is to put internals inside an ability handler that exists basically to encapsulate all the internal behaviors so they're not exposed outside the handler.

The same ideas hold true for deprecated code, minus the handler solution.

In any case, these all seemed related to the "deprecated" issue enough that I'd mention them here.