3 ms·

This is precisely why I stopped using Nim. I was going crazy trying to remember what functions were called etc. I could do from x import nil but it felt like fi

• xigoi 2y ago
  Requiring namespaces would break dot call syntax, which is one of Nim’s main features.
  • firesloth 2y ago
    It could be preserved if specifying the namespace used a different syntax. Right now, if I have the `foo` module and `bar` function, I can call `arg1.bar()`, or `foo.bar(arg1)`. But if the namespace didn't also use `.`, then it wouldn't be an issue. For sake of argument, lets choose `/` like Clojure. Then we'd get: `arg1.foo/bar()` so we can specify the namespace and uniform function call syntax is preserved.
    • xigoi 2y ago
      True. That said, would you find, say, "one,two".std/strutils/split(',') more readable than this? "one,two".split(',')
      • firesloth 2y ago
        Maybe. First, you need the module name primarily for disambiguation for compiler or possibly for readability. I wouldn't recommend requiring it for everything, eg one of the arguments against requiring naming all imported symbols explicitly is for procs that use `[ ]`. But I think the std/strutils/split counter example isn't strong for two reasons: 1. When you disambiguate in Nim, you use just the module name, not it's full path. So it would still just be `strutils/split`. 2. If we were to introduce such a syntax, we could also introduce an `import foobarbazqux as foo` alias syntax, which is present in many languages (eg JavaScript, Clojure, etc). This would also be useful if we ever had module name collisions, which has never happened to me in Nim, but doesn't seem impossible.