Date: Tue, 18 Jan 2022 16:31:50 +0000
On Tue, 18 Jan 2022 at 09:13, Marcin Jaczewski via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> pon., 17 sty 2022 o 17:22 Xavier Roche via Std-Discussion
> <std-discussion_at_[hidden]> napisaĆ(a):
> >
> > P1208R1 (
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1208r1.html)
> > introduced a very neat std::source_location feature (which is not yet
> > implemented by all compilers/libraries)
> >
> > A typical use of this new type will be involved:
> > - in a default function argument with the "call site" filled by default
> > - in a default struct/class member with the "call site" filled by default
> >
> > However, when used within a default non-type parameter of a template,
> > it does not seem that the call site is the site instantiating the
> > template itself, but the template location.
> >
> > Is this the expected behavior ? (Sorry if this is a rather silly
> question)
> >
> Probably yes, otherwise you will have multiple copies of the same
> function and if we would use class templates then it would make it
> nearly impossible
> to use as every `type<>` will be different type.
>
It's possible to make that happen already, though, with `auto = []{}` (a
lambda NTTP).
However, [support.srcloc.cons]/2 [1] refers to the "location of the
invocation of the function" which strongly suggests that the feature is
intended to apply to function default parameters, not to template default
parameters. It would be odd if this were considered to apply to function
template template default parameters and not to class template template
default parameters.
This was previously asked on SO [2], but without conclusion.
Note that MSVC (the other compiler to support std::source_location)
currently ices, but with the slightly more convoluted
template<int loc = [i = std::source_location::current().line()] { return i;
}()>
it agrees with gcc.
1.
http://eel.is/c++draft/support.srcloc.class#support.srcloc.cons-2.sentence-2
2.
https://stackoverflow.com/questions/64300746/source-locationcurrent-evaluated-as-default-non-type-template-argument
std-discussion_at_[hidden]> wrote:
> pon., 17 sty 2022 o 17:22 Xavier Roche via Std-Discussion
> <std-discussion_at_[hidden]> napisaĆ(a):
> >
> > P1208R1 (
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1208r1.html)
> > introduced a very neat std::source_location feature (which is not yet
> > implemented by all compilers/libraries)
> >
> > A typical use of this new type will be involved:
> > - in a default function argument with the "call site" filled by default
> > - in a default struct/class member with the "call site" filled by default
> >
> > However, when used within a default non-type parameter of a template,
> > it does not seem that the call site is the site instantiating the
> > template itself, but the template location.
> >
> > Is this the expected behavior ? (Sorry if this is a rather silly
> question)
> >
> Probably yes, otherwise you will have multiple copies of the same
> function and if we would use class templates then it would make it
> nearly impossible
> to use as every `type<>` will be different type.
>
It's possible to make that happen already, though, with `auto = []{}` (a
lambda NTTP).
However, [support.srcloc.cons]/2 [1] refers to the "location of the
invocation of the function" which strongly suggests that the feature is
intended to apply to function default parameters, not to template default
parameters. It would be odd if this were considered to apply to function
template template default parameters and not to class template template
default parameters.
This was previously asked on SO [2], but without conclusion.
Note that MSVC (the other compiler to support std::source_location)
currently ices, but with the slightly more convoluted
template<int loc = [i = std::source_location::current().line()] { return i;
}()>
it agrees with gcc.
1.
http://eel.is/c++draft/support.srcloc.class#support.srcloc.cons-2.sentence-2
2.
https://stackoverflow.com/questions/64300746/source-locationcurrent-evaluated-as-default-non-type-template-argument
Received on 2022-01-18 16:32:02