On Wed, Aug 4, 2021 at 2:17 PM Edward Catmur via Std-Discussion
> On Wed, 4 Aug 2021 at 16:40, Jason McKesson via Std-Discussion <email@example.com> wrote:
>> On Wed, Aug 4, 2021 at 10:28 AM Jordi Vilar via Std-Discussion
>> > Is there any deep reason for not having a constructor allowing
>> > initializing all four fields?
>> A `source_location` should either be a valid location in the source
>> (aka: the return value of some call to `current()`), or it should be
>> nonsense data.
> Why? It'd be useful to be able to refer to locations referred to in a std::stacktrace_entry,
Then whatever `stacktrace_entry` is, it should produce one. That is,
when you retrieve such an object, it should have a `source_location`
in it (or be able to construct one) that represents the location in
the source for that entry.
The user (ie: not the standard library) should not be able to
construct such a location.
Yes, you keep saying this. Why should the user not be able to construct such a location? What's the harm that could result?
> or in a program other than the current program being executed - when writing e.g. a compiler, an IDE, or some other development tool.
Why does it have to be a `std::source_location`? That type wasn't
created just to hold a couple of `char const*`s. It's supposed to mean
It's a vocabulary type. It's useful in code that talks about code. If user code can't use std::source_location, it will create alternative types and lose interoperability.
> I realize that this isn't currently allowed by the API, but that doesn't in itself make it a bad idea.
>> It should *never* store values manufactured by user
> The #line directive allows the user to store arbitrary values for file_name() and line() at compile time.
That's preprocessor magic; we're talking about the actual C++ language.
It doesn't change the fact that a std::source_location need not refer to an actual file that ever existed on disk, nor a line within such a file. So where's the harm in storing arbitrary values - which probably do refer to an actual file, just perhaps not one corresponding to the source code of the current executable?