why compiler try use my sqrt not std.math?

[Jonathan M Davis]

On Wednesday, May 8, 2019 2:52:34 AM MDT Cym13 via Digitalmars-d wrote:
> On Wednesday, 8 May 2019 at 08:48:40 UTC, Cym13 wrote:
> > On Wednesday, 8 May 2019 at 08:28:57 UTC, KnightMare wrote:
> >> [...]
> >
> > First of all, such questions are better suited for the Learn
> > section if you want quality answers.
> >
> > [...]
>
> I hadn't noticed the type issue, my answer is off.

It doesn't matter, because the local scope always wins when there's a symbol
conflict with an imported symbol. If you try to use the same name as a
symbol you're importing, and you want to use the imported symbol, then you
need to either use the full import path when using the symbol, rename it
when importing it, or alias the symbol (using the full path name) to a
different name. In the latter two cases, you then of course have to use the
new name for the symbol and not the original name. IIRC, you have the same
problem when you have a local import which imports symbols explicitly
instead of the entire module, because that effectively aliases the symbol
with that name in the local scope.

You basically can't overload symbols from other modules in the local scope,
because the language assumes that you want the local symbol. In general
though, D doesn't go with the "best match" with overload sets. It will take
the exact match, and it will do implicit conversions if there's only one
possible choice, but once multiple overloads would all accept the same type
but none of them accept the exact type of the argument, then it's an error.
D is much pickier about overloads than C++ in order to avoid issues with
function hijacking. It can get annoying sometimes, but by being pickier
about it, it avoids a whole class of bugs that exist in C++.

https://dlang.org/articles/hijack.html

- Jonathan M Davis