Added std::string_view<>

[TurkeyMan]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @TurkeyMan! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + druntime#2309"

[TurkeyMan]

string_view.cpp
test\stdcpp\src\string_view.cpp(1) : fatal error C1083: Cannot open include file: 'string_view': No such file or directory

Really? We're rolling ancient compilers here? :(

[rainers]

Really? We're rolling ancient compilers here? :(

The auto-tester builds with VS2013, string_view was added in VS2017.

[TurkeyMan]

Removed the Win64 test. I'll add it back whenever the auto-tester can run it.
I'm consuming it locally for now, so it will continue to work.

[TurkeyMan]

This is done. Can has review?

[TurkeyMan]

This is super-useful, because can finally pass D-strings between D/C++ with no local hacks!

[TurkeyMan]

cc: error: unrecognized command line option ‘-std=c++17’

Oh FFS... these testers are all vintage machines! >_<

We just have to trust that this one works, since CI can't run any of the tests (they work for me locally!)

[thewilsonator]

Please rebase

[TurkeyMan]

Difficult to test, because very few CI machines support C++17, including the Windows CI machines...

[thewilsonator]

Hmm, clearly some of them do. Why do we not have Appveyor for druntime? Then you could disable the autotester's windows builds and rely on that instead.

[TurkeyMan]

I think we might just need to merge this on faith until all the CI machines get with the now.. I use it locally, people will report bugs if it doesn't work, but honestly, it will likely get VERY low usage in the short term, since it's not that common even in C++ yet.

[thewilsonator]

Ahh I see that you haven't enabled the test.

[TurkeyMan]

This is pretty critical for D interaction though; it allows you to pass string slices to/from D. This is the C++ slice ABI that people keep complaining we need to have.

[thewilsonator]

Heh, I'd love to get
dlang/dmd#8120 merged.

[TurkeyMan]

Yeah, it would be nice... but if we have std::string_view<> and std::span<>, do we really need that hack?
I guess it's still nice for C++ to link to D code, rather than the case of D linking to C++ code (where these are useful).

[TurkeyMan]

Remove auto_merge for a minute, I just want to give it a good once-over, and run the tests comprehensively since I rebased.

[thewilsonator]

Done. Ping me when you're ready.

[jacob-carlborg]

Heh, I'd love to get dlang/dmd#8120 merged.

The problem is that the ABI for D strings and a struct with a corresponding layout doesn't match on Windows. D strings are passed in registers but not structs. So we would need to change the ABI as well in addition to the mangling for extern (C++) functions.

[TurkeyMan]

Sadly, the struct ABI is less efficient than the register pair. I would discourage changing the ABI, and instead, just use some other proxy struct in the argument list instead (ie, std::string_view, or std::span?)

[jacob-carlborg]

just use some other proxy struct in the argument list instead (ie, std::string_view, or std::span?)

Are those structs treated specially by the compiler to better optimize?

[TurkeyMan]

No. They will perform the same as if you remove D's slice ABI optimisation. I'm saying, don't change the slice ABI, just use another struct instead (perhaps these).

[jacob-carlborg]

I was thinking to change it only for extern(C++) functions.

[TurkeyMan]

And extern(C)?

[jacob-carlborg]

And extern(C)?

I didn't think of that. There's no mangling for C functions so the mangling problem doesn't exist there. But the ABI mismatch does, I guess.

[thewilsonator]

I think most perf loss can be averted with (cross language) LTO

[TurkeyMan]

VS LTO is not supported by any 3rd party toolchains.

[thewilsonator]

Of course,grumble,grumble. It does work fine for LDC/Clang and I presume GDC/G++.