Remove ambiguity in nullary remote calls with unknown targets

[josevalim]

• Deprecate map.foo() in favor of map.foo
• Deprecate mod.foo in favor of mod.foo()
• Change the AST so remote calls (A.b, a.b, etc) without parens has nil third element. Once we do so, remove :no_parens metadata usage throughout the codebase (perhaps behind the --future flag)

PS: originally this issue was about deprecating all nullary remote calls without parens, but it has been restricted since then. See this comment for more info.

[eksperimental]

What about typespecs of arity 0?

[josevalim]

@eksperimental we probably won't touch typespecs for two reasons:

1. of all of the examples above, it is the most common, which means potentially hundreds of warnings in a project

2. it can't be fully automated, which doesn't help with 1

[esse]

Is this open for contribution? Because I would love to work on that :)

[josevalim]

Hi @esse, not yet. Note it is tagged for v1.11 and we are still working on v1.10.

[josevalim]

Folks, I will go ahead and revert the changes to the pipe operator. I have been running them for the last 40 days and I have to be honest that every time I saw the warning a part of me died a bit. :)

There is nothing ambiguous on |> Foo.bar, so it makes no sense to push users to use parens. That's opposite to an unqualified bar without parens, which was ambiguous and it required revisiting the context.

Therefore, we will only apply these rules where ambiguity exists: map.foo() and mod.foo. We will likely start emitting a warning for map.foo() first and a warnings for mod.foo later.

EDIT: I have updated the original description to track only the changes we will effectively do.

[josevalim]

On v1.11 we will add this as a compile-time warning whenever we can infer it. So I will postpone this to v1.12 or maybe even v1.13.