Well, what I wanted to say is that, in addition to the canonic usage
for the source_location, that is when created by
source_location::current() as a constexpr (in this case, the
source_location is initialized to describe the point in the source
code where the source_location was created), the type could be useful
also in other scenarios, for instance, to wrap the source_location of
a stacktrace_frame. For sure, in this other case, objects of type
source_location are not constexpr, as they are initialized in runtime.
And this is where this collides with current source_location design,
as there is no way to initialize the source_location with values
provided in runtime.

My question is if there is a reason for not allowing the reuse of the
source_location for other (I think) legitimate use cases like the one
exposed.

Missatge de Jason McKesson via Std-Discussion
<std-discussion_at_[hidden]> del dia dc., 4 d’ag. 2021 a les
17:41:
>
> On Wed, Aug 4, 2021 at 10:28 AM Jordi Vilar via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
> >
> > Hi evreyone,
> >
> > I would like to ask you about your oppinion on the closed design for
> > source_location type.
> >
> > As currently designed, a source_location can be constructed by either
> > the static source_location::current() function or a default
> > constructor.
> >
> > The source_location::current() static function fills the
> > line/column/file/func fields by using compiler magic as a consteval.
> > That's great, and that's the intended usage.
> >
> > The default constructor in the other hand is of little value as there
> > is no way to initialize the internal fields in any way.
> >
> > This makes the reuse of this type impossible. For instance, the
> > stacktrace_entry could be defined by means of reusing this type to
> > convey the source location information. I don't know if it was
> > considered during the review of the stacktrace facility, in the
> > p0881r7 I only see a reference to aligning behavior with
> > source_location regarding the source_file.
>
> Can you explain a bit more what that means?
>
> If you have a source_location that was default initialized, do you
> want it to have the same value as one initialized by
> `source_location::current()`? If so, why allow it to be default
> initialized at all? Why not just force people to use `current()`?
>
> Default initialization is allowed because it's sometimes useful to
> default initialize an object into an empty state and then copy in its
> real values. So you can do `sl = source_location::current()` where
> `sl` was default constructed.
>
> > 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. It should *never* store values manufactured by user
> code.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion