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.