Should task/forall intents ignore locale-private variables?

[ronawho]

Locale private variables aren't an official feature, but I use them in some low-level tests, and I occasionally get hit by task/forall intents preventing me from accessing the current locales private version. e.g for something like:

pragma "locale private" var counter: atomic int;

coforall loc in Locales do on loc do
  counter.add(1);

coforall loc in Locales do on loc do
  write(counter, ' ');

You get 2 2 where I would expect 1 1

This is because task-intents are giving locale-1 a reference to locale-0's private var. This always confuses me at first and makes me wonder if we should ignore locale-private variables for task/forall intents (or maybe for ref intents, provide a reference to the private instance?)

[LouisJenkinsCS]

Definitely: I'd expect locale-private anything to redirect all access to the locale-private variable. Although at a high level, this could be privatized.

[vasslitvinov]

The main question to me is how special we want to make locale-private variables. For example:

• Do not apply task+forall intents to them at all. Do not create shadow variables, always access the outer variable instead. This is a "very special" option.

• DO apply task+forall intents to them. However, special-case the ref/const ref intents to access the outer variable as in the first bullet. This is a "mildly special" option.

Preferences?

[vasslitvinov]

In #16716 (comment) @bradcray suggested to consider replacing each locale-private variable using other existing language constructs. Here are the locale-private variables that we rely upon right now:

variable
_str_literal_NNN (created by the compiler)	used ~for caching
_bytes_literal_NNN	ditto
var chpldev_taskTable : unmanaged chpldev_taskTable_t?
const ref Locales
const nilLocale = new locale(localeKind.nilLocale);
var defaultLocale = new locale(localeKind.default);
var rootLocale = nilLocale;
var chpl_localeTree: chpl_localeTreeRecord;	each locale has its own value
var rootLocaleInitialized: bool;
var defaultDist = new dmap(new unmanaged DefaultDist());

[bradcray]

@bradcray suggested to consider replacing each locale-private variable using other existing language constructs

My thinking here is that it seem as though different use cases may use locale private variables in different ways, and there aren't very many total uses of them in our code base (and some of them are things we want to replace anyway, like the chpl_localeTree). So rather than adding/maintaining special-cases in the compiler for them, is there something we could do to implement them using other features? Or, if we thought they were a good feature, to turn them into a user-facing feature with well-defined semantics?