On Monday, 30 July 2018 at 19:51:09 UTC, Walter Bright wrote:
On 7/30/2018 6:45 AM, Atila Neves wrote:
On Friday, 27 July 2018 at 22:50:20 UTC, Walter Bright wrote:
On 7/27/2018 10:28 AM, Atila Neves wrote:
But all I'm trying to do here is tell the D compiler how to
mangle symbols.
Namespaces have semantic implications, too, such as overload
resolutions. A namespace introduces a new scope, not just a
mangling.
Should they, though?
They do in C++. That was the whole point of adding namespaces:
C: void ns_foo();
C++: namespace ns { void foo(); }
I meant "should they in D, though?". I don't want to import C++
semantics into D. I want D to correctly mangle C++ namespaced
functions and change nothing at all about overload resolution in
D.
Structs aren't namespaces, I wouldn't expect them to behave
the same.
From a language perspective, they are namespaces.
Technically, yes. But not C++ namespaces.
C++ has a lot of bizarre name lookup behavior.
It does. I don't think anyone is suggesting we copy it.
I didn't know about this and it makes things better, but it's
not a real solution to my problem.
See my other post doing this same thing with structs.
It's not the same - if I want to link to std::vector and
std::string, I'd expect them to be used in D as std.vector and
std.string, not std.vector and HackyDThing0.std.string.
I'm arguing that reopening should be allowed.
As detailed in another post, this opens a whole host of other
problems. Even in C++, what names are visible in a namespace at
any particular point in the compilation is a nebulous concept.
(It is actually carefully specified, but you have to be a
language lawyer / compiler implementer to know what they are -
to the user it is erratic, random, and nebulous.)
Right, but D doesn't have to do any of that - as far as D is
concerned it's just mangling. Well, as far as the typical D user
that writes `extern(C++)` anyway.
