Is it possible to provide access to namespace and its descendants throw its index?

general namespace and its descendants will have positive index from 0 for general up to 2^31.
local/blank namespaces will have same limit of negative indexes.

sintax of indexed access to namespaces could be "\Index.subitem" or "\index.\subindex".So "\0.anything" and just "anything" would mean the same.

One of my principal assumptions for the namespace features in fasmg was that they should be strongly relative - that is, you can embed an entire source in another namespace (for example to provide a separation from another one) and it should not be able to "notice" that its namespace is no longer the "true" root. All references have to be relative.

What mean it should not be able to "notice"?
If sequence .. in current namespace points to somewhere else that mean it isn`t "true" root, is it?

The .. sequence refers to a subspace of current namespace. There is no way to refer to the "parent" namespace in fasmg. The encapsulation provides a sandbox that you cannot simply break. If you put two "programs" in two parallel namespaces, they cannot access each others namespace unless the container provides explicitly with a way to do so - this is by design.

Ok, from child namespace it is impossible. From general namespace is it possible to declare tree of descendant namespaces with blank|local ones, so way that each child can acces whole that tree and each subelement of that tree?

Yes, if you define a global symbol that is not redefined locally in any of the child namespaces, then you can use it access entire local tree from anywhere within that scope: Note that if you then take that entire source and embed it within another namespace, perhaps in a larger project, it is going to work the same, no matter that the "root" variable would be in a child namespace of some larger project. This is the "relativity" I mentioned.

I wish C++ had namespaces like this (and disabled that ADL crap), would be much more useful than the current design.

Not being argumentative, but C++ has the "using" directive for namespaces like the standard (std) library (not standard template library so don't go there). I think that you could possibly get namespaces to behave as the assembler (FAsm) example above using TypeDef stuff in C/C++ too, but C++ can be a hair pulling festival. Regardless, enjoy the fact that FAsm has namespace functionality --very awesome.

As far as ADL --never felt compelled to go that deep into C++, but have seen/read many posts concerning ADL and few were positive.

FAsmG is getting to a point where compiler design isn't simply realistic, but should become exponentially easier. Mapping HLL to LLL using simple macros (translation layer) is getting far more accessible with the FAsmG macro system. I would laugh my azz off about compilers being designed with macro (static HLL compilers may be the ones that become obsolete).

FAsmG.everywhere framework --LOL
it could, and probably will happen. I can't wait.

ADL effectively "disables" namespaces for functions who have parameters taking types that are defined in the same namespace.

I find it a moronic feature because if you don't want the namespace, then don't use the namespace. ADL is the language telling you "I know what you want better than you, you probably don't want a namespace here you sucker, so I'll forcefully do it with no way for you to disable it, haha!"

With templates it's even worse since you don't even control what they get instantiated with (that's up to the user of them). You have to do ugly shit like (func)(args) when calling just to protect yourself against ADL.

ADL is a "feature" because idiots wanted to place their abuse of the shift operators into the std namespace and then act as if they're not in std namespace. So why couldn't they just place them in the fucking global namespace instead of this monstrosity?

Motto is simple: if you don't want namespaces, don't use namespaces. C++ committee can't seem to get this basic principle straight.

I am a complete noob when it comes to C/C++ stuff.

So for someone who doesn't understand what it is all about, I visit the WP page here: https://en.wikipedia.org/wiki/Argument-dependent_name_lookup

And it tells me this code can't compile without ADL So how do I define operator<< and make it compile without ADL?

Note: This is a genuine question. I don't understand

Place it in the global namespace (where main is). I mean, you call it without qualifying the namespace, that's the most sensible approach.

But no, they wanted to place it in std namespace while still having that compile without specifying the std namespace. So, why place it in a namespace again if you don't want it to be in a namespace?

When you place something in a namespace, you want it that way. ADL defeats the concept of namespaces because of their incompetency.

"But I don't want to pollute the global namespace", well guess what ADL does pollute the global lookup regardless and it is forced upon everybody. Sickening.

Consider: Fails to compile.

Because ADL brings into lookup Awesome::superFunction implicitly, defeating the whole purpose of the namespace. Clearly you meant to use the global superFunction since it's in same namespace as main, but nope. Language decided that since it takes an Awesome::S related parameter, you definitely want to use Awesome's namespace implicitly!!! "Ambiguity". ADL is a lookup pollution already.

You need to write something like (one of): and then it compiles. WTF?

If I define operator<< in the global namespace can I still use it for strings with cout and for numbers to left shift integers?

Yeah, it's a binary operator so you can make it take those parameters, and since C++ supports overloading, it won't clash with other operator<< in the global namespace (unless they have the same type, but then, why would someone else use your namespace's type in operator<< in the first place? it's an ambiguity with ADL too and fails to compile anyway)

Well you can make operators also in the class itself which implicitly take the class as the "Left-hand side" of the binary operator -- no ADL is performed there, since ADL is only performed on "free" functions (functions not within a class).

You also see "best practices" idoms such as "don't put types and functions in the same namespace unless they are related and you want ADL to work". Basically a thing that wouldn't be needed if ADL wasn't a thing.

In other words, complicate your entire hierarchy because of some incompetent decision that they just won't deprecate or at least allow to selectively remove via a keyword or whatever. Whoever thought it up was braindead.

Might as well say "put functions associated with a type that you want called without qualifying their namespace into the global namespace" and simplify the whole language without cancer like ADL.

I can see that sometimes ADL is useful, and sometimes it is annoying. I just hope the error messages are sufficiently detailed to explain to the poor (l)user what is causing the problem.

I don't know if it's ever useful since there's an alternative without any extra feature. But still, at least they need to give us a way to disable it.

Even better: make it disabled by default and ONLY enable it on functions you intentionally mark as "ADL lookup-able", for example, with a keyword on the function's declaration like "export" since that keyword already exists.

What if I have another string library and it uses operator<< to rotate the string (or whatever alternate operation I need) instead of concatenating, do I define both in the global namespace?

Yeah, there's no difference compared to ADL in this respect. It will work since functions can be overloaded based on types of arguments (of course, we do assume the library uses its own string type/class).

If it failed to overload in the global namespace for whatever reason, it would also give an ambiguous error with ADL, just as I shown in the example before (they both take the same type).

The difference is that with global namespace you get an error immediately to fix it (can't overload function with same type), with ADL you only get error when you actually end up using it because it finds two functions with the same signature so it's ambiguous to the compiler (so IMO it's even worse even for operators).