Hacker News
points by roarcher 3 days ago | 0 comments
> A lot of language are doing fine using dots.

I have implemented one such language, and while it is indeed doing fine, the dots-everywhere syntax really does complicate name resolution. It only uses it because the distinction between two different operators would be lost on its intended less-technical audience. It is a (in my opinion unfortunate) tradeoff made for a specific reason.

And one thing those languages all (as far as I know) have in common is that they do not have Rust's macro system. It may well be impossible to implement that without a distinct operator.

I have no opinion as to whether that operator should be `::` or some other arbitrary symbol, but I believe that no matter what symbol they chose, someone would complain that it doesn't fit their personal taste. Can't please everybody.

[–] Joker_vD 2 days ago
> I have implemented one such language, and while it is indeed doing fine, the dots-everywhere syntax really does complicate name resolution.

Can you share an example? In my experience, this only happens with serious reuse of names across both types and values, e.g. with something like

    struct a { 
        struct x {
            typedef int y;
            y x;
        };

        struct y {
            typedef double x;
            x y;
        };

        static x y;
        y x;
    };


    a a;
after which the unified syntax "a.x.y" could either mean a typedefed int from struct x, or a double field from struct y... but why would you even want to support such scenarios? C++, for example, prohibits namespaces from sharing the names with types and values in the same scope, and even though it uses "::" for namespace lookups, it still had to introduce "typename" keyword to explicitly disambiguate the type names from values anyhow so...
Hacker News