[cfe-dev] help wordsmithing documentation?

Nick Lewycky nlewycky at google.com
Tue Jan 21 16:16:41 PST 2014


On 21 January 2014 16:02, Sean Silva <silvas at purdue.edu> wrote:

> Why not just say that we treat the expression as the body of a constexpr
> function? That nails down the semantics quite nicely.
>

The problem I had with that is that it's very closely tied to C++. What
about the interpretation of this same thing in C mode? I was hoping for a
name for this kind of constant expression that gets evaluated with constant
arguments slotted in, but if there isn't one then I guess I'll go with
constexpr and let people implement more C++ rules in C mode. This whole
thing already relies on overload resolution.

On 21 January 2014 15:12, Warren Hunt <whunt at google.com> wrote:

> I don't know how to address your ambiguity in "evaluated by substituting"
> but I had a hard time reading "and the reason supplied in the string will
> be given to the user if their code does not compile as a result".  I would
> probably simply delete "the reason supplied in" or replace the phrase with
> "and the user provided string will be given if the code does not compile as
> a result".
>

Good catch, that can be tightened without loss of meaning.

Nick


>  On Mon, Jan 20, 2014 at 7:36 PM, Nick Lewycky <nlewycky at google.com>wrote:
>
>>  In the documentation for enable_if<http://clang.llvm.org/docs/LanguageExtensions.html#controlling-overload-resolution>,
>> I have this paragraph:
>>
>> An enable_if expression will be evaluated by substituting the values of
>>> the parameters from the call site into the arguments in the expression and
>>> determining whether the result is true. If the result is false or could not
>>> be determined through constant expression evaluation, then this overload
>>> will not be chosen and the reason supplied in the string will be given to
>>> the user if their code does not compile as a result.
>>
>>
>> The problem I have with this is that "evaluated by substituting" is
>> ambiguous. You could observe a different result if the implementation
>> performed template-instantiation style substitution, as opposed what we
>> actually do which is pretending that the expression was inside a constexpr
>> function being called with the parameters from the call-site.
>>
>> I do mention that we perform constant expression evaluation, but it
>> sounds like that happens after the substitution. Is there some more precise
>> language I could use to clarify exactly how the extension behaves?
>>
>> Nick
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140121/4137ddd4/attachment.html>


More information about the cfe-dev mailing list