Should Chapel continue supporting single-identifier statements like `ident;`? about chapel

[mppf]

I think we may rely on ident; today to force a default initialization for a variable as a means of telling the compiler not to try split-initing it across a larger code block; but that seems like a subtle/roundabout way to get that effect, and we've considered adding more direct ways to express it (e.g., var x: whatevertype = init; or var x: whatevertype = whatevertype.default). We could also write it using other subtle patterns like noop(ident); or forceInit(ident);.

We have issue #15769 about this.

On the overall issue here, I don't have a strong opinion either way.

If we choose to proceed with making it illegal, I think could deprecate it now (and have code doing var x: whatevertype; x; just emit the deprecation warning). And then, in a later release, we could add var x: whatevertype = init (or whatever), make the deprecation into an error, and adjust test code to use the new = init form.

[bradcray]

Regardless, lack of a clear/universal placeholder is what worries me.

What is the usage model for a clear/universal placeholder? (In Chapel / In general)

I appreciate the experimentation here, which I was not anticipating (and would personally celebrate having the whole ident[.ident]*; pattern marked unstable for the fall release), but I also think this deserves more design discussion than it's had before we consider it decided. So far, I think it's just a few of us paying any attention here, with me as the primary champion.

That said, if we could get agreement on the unstable warning for ident; (if not ident[.ident];*) for the release and merge what you have, I'd still consider that a win / step forward, and an opportunity to reverse ourselves in the future. I don't even think we'd need to update the standard modules given that we don't generate unstable warnings for them (?).

[e-kayrakli]

From a procedural standpoint, this scares me a little bit because of the amount of test changes required. They need to be handled individually in most cases. There maybe a universal way of reading from a symbol. For now I created a branch where I appended .locale. The diff is:

main...e-kayrakli:chapel:single-ident-unstable

Note that there are some extraneous changes because I scripted the change (#23145). Also .locale is not the correct thing to do in some cases. In any case, the diff should show places where code needed changing.

The good side of the story is that the module code changes were relatively minimal. Only interesting thing I did was in Set, but I think it should be innocent.

[bradcray]

That's a very modest number of test changes compared to do return PR (300+) or the PR I'm currently looking at! (839) :D It definitely doesn't seem like a showstopper number, anyway.

Glancing through it, I'm seeing:

• at least one sync var read that doesn't seem to be generating the deprecation warning as they should, which is concerning: test/arrays/diten/replaceArrayAccess/modifyInAnotherTask2.chpl
• lots of forcing of default init rather than split init (this is the case that worries me the most since we don't have a good alternative at present; not that I think x; is a great way of indicating "please default initialize me rather than trying to split init me")
• more uses of side-effecting paren-less routines than I would've expected, which are arguably counter to the preferred style (test/functions/iterators/vass/multi-yield-symbols/14-diffLocalSymbols.chpl)

I realize .locale is just a placeholder, but just in case: note that x.locale; would similarly be illegal by the proposal in the OP.

My takeaway is that Vass is the developer who most loves paren-less methods.

[e-kayrakli]

I realize .locale is just a placeholder, but just in case: note that x.locale; would similarly be illegal by the proposal in the OP.

Yeah. Though, arguably catching ident1.ident2; could be a bit more of a challenge. Or maybe not. Feels different enough, though.

Regardless, lack of a clear/universal placeholder is what worries me. I am not against pushing for the change in 1.32, but I am not very eager. Do you want me to pursue this?

An obvious lazy solution is to mark them unstable (that's what I have in my branch anyways), and only get rid of ident; in the standard module code while ignoring tests for the time being.

[lydia-duncan]

My memory was that we ultimately decided to continue supporting this. Is that correct? If so, I think we should close this issue

[bradcray]

I don't know that we ever put in the proposed time to discuss it in more depth, but @jabraham17 made good use of this feature to implement a debugging pseudo-statement as a library, and that took away my zeal for getting rid of it. Since I think I was the main proponent here, I agree we can close it and someone else can take up the charge if it comes up again.