Spaces are allowed in broadcast calls f. ()

[mbauman]

We dropped support for spaces between function names and parens in normal calls (#11891), but unfortunately the addition of dot-broadcasting brought this back!

julia> sin    (1)
ERROR: syntax: space before "(" not allowed in "sin ("

julia> sin.    (1)
0.8414709848078965

[mschauer]

There is a difference that the first disarms a trap

# Old julia
julia> [sin (1)]
1×2 Array{Any,2}:
 sin  1

julia> sin (1)
0.8414709848078965

while the second is harmless

julia> [sin. (1)]
1-element Array{Float64,1}:
 0.8414709848078965

julia> sin. (1)
0.8414709848078965

[Keno]

While we're at it, let's also fix the parsing of this:

julia> sin. .
ERROR: type #sin has no field .
Stacktrace:
 [1] getproperty(::Any, ::Symbol) at ./sysimg.jl:18

[JeffBezanson]

I believe this is because we intentionally allow space after the dot in a. b. I don't remember why but I think I remember some discussion about this.

[vtjnash]

I'd guess it's to allow the development of future syntax concepts? Potentially something along the lines of javascript's chaining:

a.
  b().
  c().
  (broadcast!).
  d()

But also because there's no reason (ambiguity) to disallowing it, so we let people experiment.

[JeffBezanson]

Ah yes, see #17305.

[JeffBezanson]

While we're at it, let's also fix the parsing of this:

julia> sin. .
ERROR: type #sin has no field .
Stacktrace:
 [1] getproperty(::Any, ::Symbol) at ./sysimg.jl:18

Ok, I see that that could be an error, but does this cause an actual problem?

I also suppose we could allow a. b but disallow a. (b).

[mbauman]

@shrivaa Please ask questions on the discourse message board. Folks will happily help you out there.