Chapel: Should _value and/or _instance be exposed via a user-facing interface?

[e-kayrakli]

Spin off from @ben-albrecht comment in a separate issue

The _instance field and _value method (that returns the privatized instance, if any) are not user-facing features of the domain map implementations. However, as @vasslitvinov points out they are used 50 times in modules/dists. So there is a strong precedence that needs to access those internals.

I propose we do one of:

1. Document what we have and agree that it is OK to use them from dmap code.
2. Add a more user-facing interface to access those internals. (from @ben-albrecht's comment)
3. Revise the DSI such that the users don't need to access _value or _instance from dmap code.

In an ideal world, I'd support 3. But it may be too much effort with not much to gain in the short term. 2 maybe a good compromise.

[bradcray]

If we expose these to users, I think it should be considered a very advanced user-facing feature (much like the dmap interface itself). I.e., I don't think typical users should have much need of it ideally (?).

[LouisJenkinsCS]

Given that I use it all the time, I'd want number 2.

[e-kayrakli]

@LouisJenkinsCS -- Can you characterize your use of these? I am particularly interested in uses of _value and/or _instance outside of domain map implementations. i.e. where you are using one of the already existing distributions and yet you need to access these from the application code.

[LouisJenkinsCS]

Use Case: Creating a reference to an array as a class field

(Old) https://github.com/pnnl/chgl/blob/master/src/AdjListHyperGraph.chpl#L894-L901
(New) https://github.com/pnnl/chgl/blob/master/src/Privatization.chpl#L69

Edit: Emphasis on doing this without relying on hacky compiler optimizations that may or may not work.