This makes it possible to write a top level fun starting with an uppercase letter, but there is no way to call this fun:

fun Top_Level_fun
  puts "foobar"
end

Top_Level_fun # => undefined constant Top_Level_fun

I think it's a good addition for fun in lib, but maybe not in top level. We could give a compile-time error when trying to define a top level fun like this, WDYT?

@bew Good catch. Fixed!

I strongly support this change :-)

"| Disallow top-level funs that start with Uppercase"

So no toplevel methods like the Integer and String factories in Ruby will be possible? Ok.

How will uppercase methods compare against constants in name resolution? Say you have the following:

class Foo
  class X
  end 

  def X
    return Foo
  end

  def do_it
    X.new
  end
end


x = Foo.new.do_it

which X is X?

@yxhuvud This change only applies to lib funs. So your code won't compile because def X isn't valid.

@yxhuvud And if we ever allow that, X will always refer to a constant, and X() will be the method call, just like in Ruby. But for that we'd have to change generics to use another syntax, maybe Gen<T>.

I thought that this wasn't just funs because the title is a bit confusing mentioning method calls.

Well, to be able to call funs with those names you have to allow uppercase in any call names, like in Foo.Bar and foo.Bar (because right now you can assign a lib to a variable)

Note that it's method calls, not method definitions ;-)