Hi!

First of all, thank you for the mental sider to my Saturday morning coffee. 😊 I do enjoy reading technical stuff to get my brain going.

However, I would consider taking a totally alternate route for a reason you also mention along the lines of std::span, namely to avoid „type spam”. My rhetorical question would be:

Could you import your data easily in a run-time manner? (Of course you could.)

Why introduce an entirely new way to process input, when all you intend is to be able to read files at compile time? We already have a versatile way to do that at run-time through iostreams, std::ifstream to be precise. I would much sooner vote std::ifstream and related types to gain constexpr support for many reasons:

1. Easier to teach. Everyone starts with std::cout << „Hello, World!” << std::endl; and related operations. There’s really no reason why custom type IO operators (std::istream& operator>>(std::istream& is, MyType& rhs) {…}) should not translate into this brave new world. The only thing needed is std::ifstream to work in a constexpr context.
2. You mention the troubles of how to specify file-system paths portably, which you say could be specified via embed_options. Don’t we have a way to deal with those? Oh yeah, std::filesystem, and it just happens to be that std::ifstream has matching CTORs.

AFAIK constexpr std::allocator is already in the works, which is needed for std::basic_streambuf to work in a constexpr context. I do understand that iostreams and formatting my possibly throw, which renders it unable to be used in constexpr contexts. However, avoiding „type spam” and multiple ways to get the same job done is enough incentive to consider making exceptions cx-friendly. (When I first heard that exceptions cannot be used in cx contexts, I was puzzled… Why not emit a #error or any compiler error on unhandled constexpr exceptions? It really is an error in the compilation process.) Alternatively, we could introduce a std::basic_cxios that does not have an exceptions() member and can only report errors through error_codes.

I do agree that this feature would greatly simplify tooling around the language, but I think the proposals current direction is harmful. I think it’s bloating the language (STL) in ways that are not necessary. Everyone has muscle memory in how to deal with iostreams (may that be good or bad) and we should leverage as much of that as possible for simplifying things in our heads. Having constexpr std::ofstream is a totally different pothole that can wreck havoc (translation-unit crosstalk via constexpr file output Will create dependencies of source files possibly on an intra build target level), so I’m not advocating for that, even though it might have value and C++ programmers are free to shoot themselves in the foot if they see fit. Even now there are gazillions of ways to do that. If someone believes there’s enough value down that road, they should propose.

What are your thoughts? I don’t think I’m „bikeshedding” here, so I’m curious to what you think. Is this madness?

Cheers,
Máté

Feladó: ThePhD
Elküldve: 2018. május 12., szombat 1:47
Címzett: tooling_at_[hidden]
Tárgy: [Tooling] [ std::embed ] Getting Data into C++ at Build Time

Dear SG15,
     Titus Winters at C++Now invited people to join the SG15 mailing list (which I didn't actually know existed!) and share their ideas. I wrote a paper about getting resource data from files into C++ in a cross-platform, compile-time way, under the name "std::embed" -- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1040r0.html.
     I expect the paper to be changed quite a bit as I go to my first C++ Meeting in Rapperswil, but before I do I would like to submit the paper here. It seems like something that would be of benefit to this Study Group, as it can replace many build steps currently used today to handle the same sort of issue.
     If anyone could give me feedback about the paper, what it might meant to them, or if it even is something that truly concerns Tooling, I would greatly appreciate it!