zlacker

>>andsoi+(OP)
The biggest thing I still don’t like about Nim is its imports:

    import std/errorcodes

    proc p(x: int) {.raises.} =
      if x < 0:
        raise ErrorCode.RangeError
      use x

I can’t stand that there’s no direct connection between the thing you import and the names that wind up in your namespace.

>>kbd+4Hb
100% my beef with it. same style as c++ where you never know where something comes from, when clangd starts throwing one of its fits

>>ThouYS+sTc
PMunch and summarity both already said this, but because maybe code speaks louder than words (like pictures?)... This works:

    from strutils as su import nil
    echo su.split "hi there"

(You can put some parens () in there if you like, but that compiles.) So, you can do Python-style terse renames of imports with forced qualification. You just won't be able to say "hi there".(su.split) or .`su.split` or the like.

You can revive that, though, with a

    template suSplit(x): untyped = su.split x
    echo "hi there".suSplit`

That most Nim code you see will not do this is more a cultural/popularity thing that is kind of a copy-paste/survey of dev tastes thing. It's much like people using "np" as the ident in `import numpy as np`. I was doing this renaming import before it was even widely popular, but I used capital `N` for `numpy` and have had people freak out at me for such (and yet no one freaking out at Travis for not just calling it `np` in the first place).

So, it matters a little more in that this impacts how you design/demo library code/lib symbol sets and so on, but it is less of a big deal than people make it out to be. This itself is much like people pretending they are arguing about "fundamental language things", when a great deal of what they actually argue about are "common practices" or conventions. Programming language designers have precious little control over such practices.