<br><br><div class="gmail_quote">On Sat, Oct 20, 2012 at 9:24 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Oct 19, 2012, at 23:27 , Andy Gibbs <<a href="mailto:andyg1001@hotmail.co.uk">andyg1001@hotmail.co.uk</a>> wrote:<br>
<br>
> On Saturday, October 20, 2012 7:50 AM, Chandler Carruth wrote:<br>
>> [...snip...] Let me hypothesize a different interface:<br>
>><br>
>> This stays the same...<br>
>> constexpr int constexpr_strncmp(const char *p, const char *q, size_t n) {<br>
>> return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : constexpr_strncmp(p+1, q+1, n-1);<br>
>> }<br>
>><br>
>><br>
>> But here we do something different on the actual declaration:<br>
>> [[constexpr_alias(constexpr_strncmp)]]<br>
>> int strncmp(const char *p, const char *q, size_t n);<br>
>><br>
>> When parsing the *declaration* of this function, we lookup the function<br>
>> name passed to constexpr_alias. We must find a constexpr function with an<br>
>> identical signature. Then, at function invocation substitution of strncmp,<br>
>> we instead substitute the body of constexpr_strncmp.<br>
>><br>
>> This seems more direct (no redirection in the code), and it also provides<br>
>> a specific advantage of allowing this to be easily added to an existing<br>
>> declaration in a declaration-only header file without impacting or<br>
>> changing the name of the runtime executed body or definition.<br>
><br>
> I'd be very happy with this solution.  I come across precisely the problem<br>
> raised by Richard on a very regular basis and have different workarounds<br>
> for both gcc and clang.  I'd love to see something "standard" emerging!<br>
><br>
> For my side, I'd still like some way of declaring a function to be used<br>
> only in a constexpr environment, meaning that the compiler gives an error<br>
> up front when a function is then used in a non-constexpr environment.  The<br>
> above proposal will provide a link-time error if the non-constexpr function<br>
> is not defined, which is half-way there.  Perhaps using the "unavailable"<br>
> attribute in conjunction with "constexpr_alias" would be the compile-time<br>
> solution...<br>
<br>
While throwing things out there, why not just optionally allow constexpr functions to coexist with non-constexpr functions of the same name, like inline and non-inline? That would solve both the original problem and Andy's problem.<br>

<br>
  // Primary declaration.<br>
  int strcmp(const char *p, const char *q, size_t n);<br>
<br>
  // This declaration will be used in any constexpr contexts.<br>
  // Non-constexpr contexts will use the declaration above (which may be inline)<br>
  constexpr int strcmp(const char *p, const char *q, size_t n) {<br>
    return !n ? 0 : *p != *q ? *p - *q : !*p ? 0 : strcmp(p+1, q+1, n-1);<br>
  }<br>
<br>
This avoids both new builtins and having to come up with a manually-mangled name for the alternate implementation. But it is most definitely a language change.<br>
<br>
And for Andy's problem, you'd then get...something like this?<br>
<br>
  constexpr int foo(int n) {<br>
    return n + 1;<br>
  }<br>
<br>
  int foo(int n) = delete;<br>
<br>
...but I have not thought about the problems in implementing this.<br>
Jordan<br></blockquote><div><br>So, what you are basically proposing is that `constexpr` would allow differenciating between two overloads much like `const`, `volatile`, `&` and `&&` do for class methods ?<br>
<br>It's a rather bold change but I agree it could integrate nicely in C++ since we already have the concept of overload, thus the machinery to deal with it and the users being used to it.<br><br>-- Matthieu <br></div>
</div>