I wish we would stop xxx::yyy::zzz for namespace.
It was horrible in C++ from day one, and is still horrible in Rust.
It had some reason to be this way in C++ but not in any other newer language.
Real negative part: it looks to me that the authors of those languages are parroting other languages rather than understanding the reason of those language choice.
This simply worries me because I judge the level of expertise and makes me not consider the language in the first place.
(I know C++ and Rust are alive but they share their fair share of poor design choice)
[–] roarcher 3 days ago
[–] kreco 3 days ago
However, I believe Rust purposely imitated C++, for reasons. And I still don't like it.
A lot of language are doing fine using dots. And if you are going to use '::' you can have your reasons. I would still find it annoying to type and read.
Just to add precision: I critic the syntax (which is very subjective), and I critic the parroting, as two separated arguments.
[–] roarcher 3 days ago
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
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;
[–] mantomat 3 days ago
I don't get it. Is it syntactically horrible or are there real reasons that I'm missing?
[–] ModernMech 3 days ago
[–] kreco 3 days ago
[–] edf13 3 days ago
[–] kreco 3 days ago
From "A History of C++: 1979− 1991".
> In C with Classes, a dot was used to express membership of a class as well as expressing selection of a member of a particular object. This had been the cause of some minor confusion and could also be used to construct ambiguous examples. To alleviate this, :: was introduced to mean membership of class and . was retained exclusively for membership of object.
It was taken from Algol68.
Then, this was reused for namespaces for consistency reason.
[–] packetlost 3 days ago
I write Rust mostly for my day job (and it's also my preferred language on the side these days), so I usually end up explicitly importing all the symbols I actually use because module::func is just additional noise in an already pretty verbose language and is what's considered 'idiomatic'.
I don't really get the issue with :: being the separator used here. It's slightly ugly, but it's visually distinct from . for field access, which I do appreciate.
[–] aeve890 3 days ago
[–] jordan_bonecut 3 days ago
[–] bigbuppo 3 days ago
[–] jordan_bonecut 3 days ago
[–] kreco 3 days ago
I just like "dots" for everything, and there are some reasons to distinguish package/module qualification, struct/class member access (.), or static member access (::).
I don't mean this to sound combative, but I think you are the one who doesn't understand the reason for the language choice. I assume you're objecting to the fact that these languages use different operators for module/namespace paths (`::`) and object member/method access (`.`), not the `::` symbol specifically.
You seem to assume that Rust blindly imitated C++, but that's not the case. The `::` syntax allows the compiler to identify and resolve all the static paths before any type inference or other analysis. This is important because macros are expanded between these stages, and can in turn introduce more static names which must also be resolved before any further compilation.
You might be able to introduce a rule that any `.`-path that can be resolved statically will be, trumping any non-static members (or maybe not, it might cause ambiguities I'm not thinking of), but Rust's stated design philosophy favors explicitness.
I don't know what this language's reason for using it was, as I don't see any mention of macros. But in general it simplifies compiler design. If you can resolve all the static names up front, the following compiler stages can ignore the concept of namespaces altogether.