https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80780
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #2)
> When I made the built-ins constexpr in bug 66561 I thought (assumed) the
> intent was for the source_location default ctor and current() member to make
N.B. my current impl doesn't do that for the default ctor, only the current()
function. I could move the default arguments to the ctor and then change it to:
struct source_location {
static constexpr source_location current(source_location c = {})
{ return c; }
constexpr source_location(const char* __file = __builtin_FILE(), ...) ...
};
This makes the current() function redundant, except for being more explicit
about the intent and so more readable.
> use of default arguments to populate the members. That's a nice, general
> solution. Treating the class as special seems like a hack to me. Why do
> you think it would be nice to do that?
I didn't mean an ugly hack would be nice, just that having the signature match
what the TS says would be nice. But it's not very important. It only matters if
somebody tries to make use of &source_location::current and the result of using
that is unspecified (and in practice won't be useful).
> My own preference would be to change the TS to both make the intent clear,
> and make it possible to set the parameters of the location.
I'd be OK with that.
> Adding __builtin_PRETTY_FUNCTION is easy but I don't know about
> __builtin_COLUMN(). The latter is also so underspecified that I'm not sure
> how it could be relied on for anything useful.
Agreed. The only use for it I thought of is if you have a macro that expands to
something huge and complex on a single line, it would let you distinguish
different positions within the expansion. But even that seems not terribly
useful. Returning 0 for the column is conforming, and if users are happy with
that then we can give useful feedback to WG21 that the column function isn't
needed.
