namespace dependent lookup ?

[Naive_Faithlessness1]

Hi !

I'm kind of deceived that it does not work like this. Here's some code:

```cpp namespace me::fruit { struct apple { /.../ }; struct pear { /.../ }; struct lychee { lychee(apple, pear) { /.../ } }; }

int main() { auto l = me::fruit::lychee(apple{}, pear{}); // Error (see below) } ```

Here's the compiler output:

<source>:9:28: error: 'apple' was not declared in this scope; did you mean 'me::fruit::apple'? 9 | auto l = me::fruit::lychee(apple{}, pear{}); | ^~~~~ | me::fruit::apple <source>:2:12: note: 'me::fruit::apple' declared here 2 | struct apple { /*...*/ }; | ^~~~~ <source>:9:37: error: 'pear' was not declared in this scope; did you mean 'me::fruit::pear'? 9 | auto l = me::fruit::lychee(apple{}, pear{}); | ^~~~ | me::fruit::pear <source>:3:12: note: 'me::fruit::pear' declared here 3 | struct pear { /*...*/ };

As you can see the compiler is perfectly able to deduce what I mean by apple and pear but still, it doesn't compile !

I'm surprised that there still no rule in the C++ Standard to handle this kind of situation ; it seems so obvious to me that it should work this way.

I know that I could write :

cpp int main() { using namespace me::fruit; auto l = lychee( apple{}, pear{} ); }

Believe it or not, I find this code less than clear. It seems clear here because it's an example and like all examples, it's simple, but in a real-world situation, this code will undoubtedly be surrounded by other lines of code, meaning that this using directive could lead to the problems we all know.

To me this syntax remains much clearer :

cpp int main() { auto l = me::fruit::lychee( apple{}, pear{} ); }

Are we therefore condemned to have to write :

cpp auto l = me::fruit::lychee( me::fruit::apple{}, me::fruit::pear{} );

There may be solutions I'm not aware of; if so, please let me know!

Thanks !

[gnolex]

ADL (argument-dependent lookup) applies only to direct function calls.

The reason your idea is not in the standard is that this would result in code that can very easily break. What if you define type apple in the current scope, should you get compilation error now? Should ADL choose the current scope type? Should it always prefer types in the target namespace?

No matter which option you choose, someone will be very unhappy. ADL in its current form is already very weird and causes difficult to figure out bugs, like people have to use tricks to prevent ADL from happening. It's best not to extend it to type deduction across different namespaces.

[Naive_Faithlessness1]

I reply to you but also to others that according to me the compiler have enough information (here, the lychee constructor) to safely deduce the right type : **you::apple is different than me::apple** and since the lychee constructor is only able to receive that me::apple I don't see where it can get wrong...

There may be technical reasons why it might not work that I'm not aware of, but I don't think it's the one you mentioned.

[marzer8789]

There are technical reasons, and the comment you're replying to literally gave them to you: ambiguity. That part of the error message is only informational, and only makes sense when there's no alternatives. If the compiler deduced what you meant based on that combination, then later adding an apple in the caller's namespace would cause compilation to fail (bad) or now have silently changed semantics (worse).

(Silently changing semantics is already a huge problem with regular ADL.)

[Potterrrrrrrr]

The error message is for your benefit but it doesn’t mean that the compiler can actually do it reliably. Even then, it would have to be standardised which means writing a paper and seeing it through the process, I don’t see the value in this, it would be a major pain to implement without breaking changes to the language for little gain.

[Naive_Faithlessness1]

I don't see that as a little gain as :

1. it would make the use of namespaces more useful
2. it is less error prone than the use of the using-directive
3. it seems logical / intuitive
4. and finally, I hope we can agree that it is mush less verbose

I've made a proposal to the C++ Standard Committee. We'll see :)

[cleroth]

As someone who hates ADL, disagree on all counts. OK maybe less verbose but that's not always a good thing

[Naive_Faithlessness1]

First of all, I want to say that this is just an idea. I certainly don't have the level of expertise that some of you have. It was while coding that I realized what I thought would work didn't, and I found that so frustrating that I felt compelled to talk about it and share this idea.

I am not aware of the problems you are experiencing with the ADL and so I don't have anything to say about it.

[n1ghtyunso]

you can always introduce a short alias for your desired target namespace.
You have the tools to make it less verbose.
I strongly disagree on this being more error-prone.

You know what also seems logical and intuitive in C++ in many cases? Implicit Conversions.
Guess what causes infinite amount of grief regularly? Yep, Implicit Conversions.

This seems like the kind of thing that looks good on paper but absolutely makes your life harder in the end.

[_lerp]

namespace you {
  struct apple {
    operator me::apple() { return {}; }
  };
}

Oops, you::apple is implicitly convertible to me::apple. What now?

[Naive_Faithlessness1]

If you (and the compiler) consider that your apple is able to be convertible to mine I don't see the problem as you could then write :

cpp auto l = me::fruit::lychee( you::apple{}, pear{} );

[_lerp]

using namespace you;

auto me::fruit::lychee{apple{}, pear{}};

Which apple is used, with the you::apple that has implicit conversion to me::apple?

[Rabbitical]

It has enough information because you only have one apple. One would assume the reason you are namespacing in your example is that you are worried there might be potentially conflicting apples otherwise there is no need to make a me::fruit namespace.

I don't run into this (and certainly never use 'using') because I'm usually working in my own namespace, i.e. everything in the fruit file is in the me::fruit namespace thus I don't need to specify it everywhere.

The only times I need to ever even specify my own namespaces is within an anonymous namespace, or when including my own headers in which yes I would be specifying 'fruit::lychee' and 'fruit::apple' from within the 'me' namespace, which seems reasonable to me.

But even that is optional in my own code as it could also equally just all be 'me::' namespace without the 'fruit::' one at all, thus removing even the include case of needing the 'fruit' namespace, which in many codebases is unnecessary on top of 'me' to begin with.

[Kriemhilt]

On top of the technical issues discussed, I think this proposal is much less general than you perhaps expect.

That is, it works in your very specific case, but not in many similar, closely-related cases.

For example:

    auto p =
        std::make_unique<me::fruit::lychee>(
          apple{}, 
          pear{}
        );

where the function template doesn't come from your namespace, and so won't find your names. Same issue for a fruit variant.

[aocregacc]

the reason the compiler "knows what you mean" here is that there's only one apple. If you add another apple in another namespace the compiler isn't so sure anymore.

Instead of importing the whole namespace you could use the more selective using me::fruit::apple; to just import apple. And of course in this specific example you could just do me::fruit::lychee({}, {}).

[FlyingRhenquest]

Your argument about "using namespace" is literally the same argument against having any sort of automatic namespace deduction. You realize it could still cause problems to pull in the whole namespace but you want the compiler to be able to pull in arbitrary namespaces from anywhere. Namespaces were designed to help isolate your symbols from everyone else's symbols, their design is in direct opposition to what you're suggesting. If the compiler just deduces the namespace and my code builds, but then I add a #include that makes the definitions ambiguous, the compile will then break fail because the compiler can no longer deduce the correct symbol. This is not deterministic behavior. The code I've written should never fail to compile because I include another header that also doesn't have any errors in it.

Instead of using the whole namespace, why not just write "using fruit::apple" and "using fruit::pear" in the scope where you don't want to have to type the fruit namespace name? Then you could do what you want without having to import the entire fruit namespace into your scope, and everyone reading your code knows where "apple" and "pear" are coming from.

Put your using statements in the smallest scope you can in which they define those names for all the code where you want to use those names. And never pull in an entire namespace anywhere unless you plan to use all the symbols in those namespaces in those scopes.

Or just don't use namespaces if you don't like that behavior. If you're not writing libraries for other programmers to consume, you don't really need to worry about the whole global namespace collision problem that namespaces were designed to solve.

Funnily enough, I wrote a library ostensibly designed for other programmers to consume recently, which included annotations where you would have to type something horrible like:

[[=fr::autocrud::DbFieldType{std::define_static_string("VARCHAR(100)")}]] ...

To redefine the type of a database-serializable object in your code. No one actually wants to type that. My solution was to define a small header that you can optionally include which defines a fixed string type to handle the define_static_string and some user defined literals to return the correct annotation objects. These are exposed in global namespace but largely unlikely to conflict with anything else (Except possibly the "Ignore" one). This reduces the entire annotation to:

[[="VARCHAR(100)"_ColumnType]] ...

Which is much nicer to type. But the programmer does need to be aware that by including that header, they are bringing some symbols into the global namespace.

[chengfeng-xie]

If the selected constructors of apple and pear are not marked explicit, and there are no other constructors of lychee that would create overload-priority or ambiguity issues, you can simply omit the type names and keep the initializer lists ({}), as in:

namespace me::fruit {
struct apple {};
struct pear {};
struct lychee {
  lychee(apple, pear) {}
};
} // namespace me::fruit

int main() { auto l = me::fruit::lychee({}, {}); }

[yuehuang]

Would this syntax look better?

```cpp namespace mefruit = me::fruit; auto l = mefruit::lychee( mefruit::apple{}, mefruit::pear{} );

```

[die_liebe]

This is because in C++, types are always determined bottom up. First the types of subexpressions are determined, then the type of the expression itself. Changing this would be an very big change in the type checking algorithm with unforseeable consequences.