Date: Wed, 4 Aug 2021 21:49:34 +0100
On Wed, 4 Aug 2021 at 20:21, Jason McKesson via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> On Wed, Aug 4, 2021 at 2:17 PM Edward Catmur via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
> >
> > On Wed, 4 Aug 2021 at 16:40, Jason McKesson via Std-Discussion <
> std-discussion_at_[hidden]> 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
> something.
>
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
> >> code.
> >
> >
> > 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?
std-discussion_at_[hidden]> wrote:
> On Wed, Aug 4, 2021 at 2:17 PM Edward Catmur via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
> >
> > On Wed, 4 Aug 2021 at 16:40, Jason McKesson via Std-Discussion <
> std-discussion_at_[hidden]> 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
> something.
>
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
> >> code.
> >
> >
> > 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?
Received on 2021-08-04 15:49:47