String lang-lib function, join doesn't work with join() syntax but only with 'join()

[dulajdilshan]

Array langlib function, map() works fine with map() as well as 'map() syntax. But, the string lang-lib function, join() shows an error withjoin() synatax

Note: it is working fine with 'join()

Shouldn't we allow both join() and 'join() with strings?

public function main() {
    string[] hello = ["1", "2"];
    int[] mapResult = hello.map(function (string a) returns int {
        return 12;
    });
}     // this works fine

string sVal = "sss".join("a", "b");        // Gives a compilation error

Related issue: #29494

@hasithaa @mohanvive @rdhananjaya @nadeeshaan @pubudu91 any thoughts?

[mohanvive]

Haven't we discussed this in our last chat? I have a long memory of this.

I think it is not a question only about "join". We have to decide how we will handle all the lang-lib functions that have the keyword names.

"map" is a special case already. In my view, we should have similar behaviour. Either we have to special case all the matching cases or remove the special case handling for "map".

[dulajdilshan]

Yeah, @mohanvive I created this discussion to track it.

[lochana-chathura]

map is an edge case here. We have a special-cased map in the parser when parsing the identifier. In all other, reserved keyword cases a quote has to be used to get it parsed.

With this: ballerina-platform/ballerina-spec#34, We'll relax more keywords to be used as identifiers

[lochana-chathura]

As per #31830 (comment) yeah. We have to think about consistency. We should either recommend ' as practice. Or we have to support all cases.

[nadeeshaan]

IMHO, if we are going to special-case a certain set of constructs then again at the semantic API POV we will have to special case also. Hence I'm +1 to maintain the consistency for all the cases

[lochana-chathura]

Updating the discussion.

We allowed map, start, and join without ' in method-call-expr with PR #33515 as per the spec issue ballerina-platform/ballerina-spec#958

[mohanvive]

Guys, later we had a chat on this since we came across some other cases as well. It seems, it is impossible to special case all these scenarios at the LS level because we have to hack multiple places to handle not only completions but also references, go-to definition and renaming. It could lead to a nightmare to handle all these cases at LS.

At the same time, this could turn into a critical blocker in near future, specifically for Choreo use cases because the suggestions provided at source view and expression editor are incorrect (we suggest without the single quote) and could break the code. As I understood, we have to come up with the proper plan/design to handle these cases seamlessly.

@sameerajayasoma @hasithaa Appreciate it if we could prioritize this (if GA is not a viable option then we should consider the immediate update at least)

[1] ballerina-platform/ballerina-spec#34 (comment)